Methods and apparatus for multi-stage assessment of locate request tickets

ABSTRACT

Locate and/or marking operations involve detecting and/or marking a presence or an absence of at least one underground facility within a dig area, wherein at least a portion of the dig area is planned to be excavated or disturbed during excavation activities. One or more attributes of a locate and/or marking operation requested in a locate request ticket are assessed to provide one or more ticket assessment outcomes. In a first stage of assessment, a first assessment outcome is produced by analyzing at least some ticket information obtained from the locate request ticket. In a second stage of assessment, a second assessment outcome is produced based at least in part on the first assessment outcome. The first and/or second ticket assessment outcome(s) is/are transmitted and/or stored so as to facilitate clearing the locate request ticket and/or dispatching a locate technician to perform the locate and/or marking operation.

CROSS-REFERENCE TO RELATED APPLICATION

This application claims a priority benefit, under 35 U.S.C. §120, as acontinuation (CON) of U.S. Non-provisional application Ser. No.12/823,028, entitled “METHODS AND APPARATUS FOR ASSESSING LOCATE REQUESTTICKETS,” filed Jun. 24, 2010, under Attorney Docket No.D0687.70034US01.

Ser. No. 12/823,028 claims a priority benefit, under 35 U.S.C. §119(a),to Canadian application Ser. No. (not yet assigned), entitled “METHODSAND APPARATUS FOR ASSESSING LOCATE REQUEST TICKETS,” filed on Jun. 23,2010, under Attorney Docket No. PAT 71588-1 CA.

Ser. No. 12/823,028 claims a priority benefit, under 35 U.S.C. §119(e),to U.S. Provisional Patent Application No. 61/220,491, entitled “METHODSAND APPARATUS FOR ASSESSING FIELD SERVICE OPERATION TICKETS,” filed onJun. 25, 2009 under Attorney Docket No. D0687.70034US00.

Each of the above-identified applications is incorporated by referenceherein in its entirety.

BACKGROUND

Fixed and mobile computer-based information systems are becomingcheaper, more rugged, and increasingly networked. As a result,technological advances are changing the way businesses collect, analyze,and manage information. For example, certain processes and certain typesof equipment and instrumentation are becoming more automatic in nature,especially with regard to the capture and manipulation of data and theconversion of data into useful information.

The area of field service operations is an example of an area that isexperiencing growth in information technology. Field service operationsmay be any operation in which companies dispatch technicians and/orother staff to remote locations in order to perform certain activities,for example, installations, services and/or repairs. Field serviceoperations may exist in industries, such as, but not limited to, networkinstallations, utility installations, security systems, construction,medical equipment, heating, ventilating and air conditioning (HVAC) andthe like.

An example of a field service operation in the construction industry isa so-called “locate and marking operation,” also commonly referred tomore simply as a “locate operation” (or sometimes merely as “a locate”).In a typical locate operation, a locate technician visits a work site inwhich there is a plan to disturb the ground (e.g., excavate, dig one ormore holes and/or trenches, bore, etc.) so as to determine a presence oran absence of one or more underground facilities (such as various typesof utility cables and pipes) in a dig area to be excavated or disturbedat the work site.

In many states, an excavator who plans to disturb ground at a work siteis required by law to notify any potentially affected undergroundfacility owners prior to undertaking an excavation activity. Advancednotice of excavation activities may be provided by an excavator (oranother party) by contacting a “one-call center.” One-call centerstypically are operated by a consortium of underground facility ownersfor the purposes of receiving excavation notices and in turn notifyingfacility owners and/or their agents of a plan to excavate. As part of anadvanced notification, excavators typically provide to the one-callcenter various information relating to the planned activity, including adescription of the dig area to be excavated or otherwise disturbed.

FIG. 1 illustrates an example in which a locate operation is initiatedas a result of an excavator 110 providing an excavation notice to aone-call center 120. An excavation notice also is commonly referred toas a “locate request,” and may be provided by the excavator to theone-call center via an electronic mail message, information entry via awebsite maintained by the one-call center, or a telephone conversationbetween the excavator and a human operator at the one-call center. Thelocate request may include an address or some other location-relatedinformation describing the geographic location of a work site at whichthe excavation is to be performed, as well as a description of the digarea (e.g., a text description), such as its location relative tocertain landmarks and/or its approximate dimensions, within which thereis a plan to disturb the ground.

Based on this information, the one-call center identifies certainunderground facilities that may be affected by the proposed excavationat the work site. For example, one-call centers generally have access tovarious existing maps of underground facilities in their jurisdiction,referred to as “facilities maps.” Facilities maps typically are providedby underground facilities owners within the jurisdiction and show, forrespective different utility types, where underground facilitiespurportedly may be found relative to some geographic reference frame orcoordinate system (e.g., a grid, a street or property map, GPS latitudeand longitude coordinates, etc.).

Most often, using such facilities maps, a one-call center identifies asignificant buffer zone around an identified work site (i.e., based onthe address or location information provided by an excavator in thelocate request), so as to make an over-inclusive identification ofunderground utilities that are implicated by the proposed excavation(e.g., to err on the side of caution). This practice of creating abuffer zone around an identified work site with reference to one or morefacilities maps commonly is referred to as generating a “polygon” or“polygon map.” Based on these generally over-inclusive polygons (and insome instances significantly over-inclusive polygons), the one-callcenter identifies all of the underground facilities that may fall withinthe polygon so as to notify the corresponding facility owners and/ortheir agents of the proposed excavation. Again, it should be appreciatedthat polygons or polygon maps utilized by one-call centers for thispurpose typically embrace a geographic area that includes but goes wellbeyond the actual work site, and in many cases the geographic areaenclosed by a given polygon is significantly larger than the actual digarea in which excavation or other similar activities are planned.

Once facilities implicated by the locate request are identified by aone-call center (e.g., via the polygon process), the one-call centergenerates a “locate request ticket” (also known as a “locate ticket,” orsimply a “ticket”). The locate request ticket typically identifies thework site of the proposed excavation and a description of the dig area,typically lists on the ticket all of the underground facilitiesimplicated by the proposed excavation (e.g., by providing a member codefor the facility owner of an underground facility that falls within agiven polygon), and may also include various other information relevantto the proposed excavation (e.g., the name of the excavation company, aname of a property owner or party contracting the excavation company toperform the excavation, etc.). The one-call center sends the ticket toone or more underground facility owners 140 and/or one or more locateservice providers 130 (who may be acting as contracted agents of thefacility owners) so that they can conduct a locate and marking operationto verify a presence or absence of the underground facilities in the digarea. For example, in some instances, a given underground facility owner140 may operate its own fleet of locate technicians (e.g., locatetechnician 145), in which case the one-call center 120 may send theticket to the underground facility owner 140. In other instances, agiven facility owner may contract with a locate service provider toreceive locate request tickets and perform a locate and markingoperation in response to received tickets on their behalf.

More specifically, upon receiving the locate request, a locate serviceprovider or a facility owner (hereafter referred to as a “ticketrecipient”) may dispatch a locate technician to the work site of plannedexcavation to determine a presence or absence of one or more undergroundfacilities in the dig area to be excavated or otherwise disturbed. Afirst step for the locate technician includes utilizing an undergroundfacility “locate device,” which is an instrument for detectingfacilities that are concealed in some manner, such as cables and pipesthat are located underground, to verify the presence or absence ofunderground facilities indicated in the locate request ticket aspotentially present in the dig area (e.g., via the facility owner membercodes listed in the ticket). An underground facility locate device isused to detect electromagnetic fields that are generated by a “test”signal provided along a length of a target facility to be identified.Locate devices typically include both a signal transmitter to providethe test signal (e.g., which is applied by the locate technician to atracer wire disposed along a length of a facility), and a signalreceiver which is generally a hand-held apparatus carried by the locatetechnician as the technician walks around the dig area to search forunderground facilities. The signal receiver indicates a presence of afacility when it detects electromagnetic fields arising from the testsignal. Conversely, the absence of a signal detected by the receiver ofthe locate device generally indicates the absence of the targetfacility.

Subsequently, the locate technician then generally marks the presence(and in some cases the absence) of a given underground facility in thedig area based on the various signals detected (or not detected) usingthe locate device. For this purpose, the locate technicianconventionally utilizes a “marking device” to dispense a markingmaterial on, for example, the surface of the ground along a detectedunderground facility. Marking material may be any material, substance,compound, and/or element, used or which may be used separately or incombination to mark, signify, and/or indicate. Examples of markingmaterials may include, but are not limited to, paint, chalk, dye, and/oriron. Marking devices, such as paint marking wands and/or paint markingwheels, provide a convenient method of dispensing marking materials ontosurfaces, such as onto the surface of the ground.

In some environments, arrows, flags, darts, or other types of physicalmarks may be used to mark the presence or absence of an undergroundfacility in a dig area, in addition to or as an alternative to amaterial applied to the ground (such as paint, chalk, dye) along thepath of a detected utility. The marks resulting from any of a widevariety of materials and/or objects used to indicate a presence orabsence of underground facilities generally are referred to as “locatemarks.” Often, different color materials and/or physical objects may beused for locate marks, wherein different colors correspond to differentutility types. For example, the American Public Works Association (APWA)has established a standardized color-coding system for utilityidentification for use by public agencies, utilities, contractors andvarious groups involved in ground excavation (e.g., red=electric powerlines and cables; blue=potable water; orange=telecommunication lines;yellow=gas, oil, steam). In some cases, the technician also may provideone or more marks to indicate that no facility was found in the dig area(sometimes referred to as a “clear”).

As mentioned above, the foregoing activity of identifying and marking apresence or absence of one or more underground facilities generally isreferred to for completeness as a “locate and marking operation.”However, in light of common parlance adopted in the constructionindustry, and/or for the sake of brevity, one or both of the respectivelocate and marking functions may be referred to in some instances simplyas a “locate operation” or a “locate” (i.e., without making any specificreference to the marking function). Accordingly, it should beappreciated that any reference in the relevant arts to the task of alocate technician simply as a “locate operation” or a “locate” does notnecessarily exclude the marking portion of the overall process.

The locate service provider 130 may handle a high volume of locaterequests on a daily basis. For example, the locate service provider 130may have locate offices (or profit centers) in different geographicalregions and each locate office may have a hundred or more locatetechnicians in the field each day. Depending on its size, each locateoffice may respond to hundreds or even thousands of locate requests on agiven day.

The locate service provider 130 may use one or more ticket processingsystems to process incoming locate request tickets from the one-callcenter 120. For example, the ticket processing system may extractidentifying information such as a ticket number from an incoming ticketand create a database entry for that ticket number. The database entrymay be used throughout the life cycle of the ticket to keep track ofpertinent information, such as the status of the ticket (e.g., whetherthe ticket has been dispatched to a locate technician and, if so, whichlocate technician).

The ticket processing system may populate the database entry withadditional information retrieved from the ticket. For example, if theticket includes an address for a corresponding work site, the ticketprocessing system may store the address in an appropriate field in thedatabase entry.

SUMMARY

The inventors have appreciated that, although the Pipeline SafetyReauthorization Act of 1988 requires all states to establish one-callcoverage for pipelines, the specific operations and practices ofone-call centers may vary from region to region. For example, differentjurisdictions may have different regulations regarding ticket content(e.g., the minimum amount of information that must be included in aticket) and ticket due date (e.g., the deadline by which a locateoperation must be performed in response to an incoming ticket).

Also, different one-call centers may obtain information from differentsources and package the information into tickets in different manners.For example, depending on the particular excavator who provides anexcavation notice and the particular one-call center that accepts andprocesses the excavation notice, a resulting locate request ticket mayidentify the location and boundaries of a proposed work site/dig area ina number of different ways, using street addresses, map grids, and/orlatitudinal and longitudinal (lat/long) coordinates.

The inventors have appreciated that such disparities in ticketinformation may have adverse effects on the quality and efficiency oflocate operations. For example, inadequate or inaccurate informationregarding the work site and/or dig area location may cause delays inlocate operations (e.g., a locate technician may be unable to ascertainthe exact location and/or boundaries of the work site and/or dig areaduring a first visit and may need to return to the work site at somelater time when improved location information becomes available). Thesedelays may increase the operating costs of a locate service provider andmay also increase the risk of damaging underground facilities.

The inventors have further appreciated that conventional ticketprocessing systems used by locate service providers may have limitedassessment capabilities. That is, conventional ticket processing systemsmay offer limited capabilities in deriving information that is notexplicitly included in the incoming tickets. For example, little or noassessment is done to estimate various aspects (or attributes) of arequested locate operation, such as location, scope, time, complexity,risk, value, resource requirements and the like. The lack of informationregarding these and other aspects of locate request tickets may lead tovarious inefficiencies, e.g., in the scheduling of the locate operationsand/or the allocation of resources to the locate operations. There mayalso be an increased risk of damaging underground facilities. As aresult, profitability of the locate service providers may be adverselyaffected.

Thus, the inventors have recognized a need for improved informationmanagement, dissemination, and utilization in the locate industry andother field service industries in which mobile technicians aredispatched in response to incoming service requests.

In view of the foregoing, one embodiment of the present invention isdirected to an apparatus for assessing one or more attributes of alocate operation requested in a locate request ticket. The apparatuscomprises at least one processor programmed to extract ticketinformation from the locate request ticket at least in part by parsingthe locate request ticket; apply one or more business rules to at leastsome of the ticket information to obtain a ticket assessment outcome foreach of the one or more attributes; and dispatch at least one locatetechnician to perform the locate operation, based at least in part onthe ticket assessment outcome for each of the one or more attributes.

Another embodiment is directed to an apparatus for assessing acomplexity of one or more locate operations requested in a locaterequest ticket. The apparatus comprises at least one processorprogrammed to extract one or more information elements from the locaterequest ticket, and associate one or more complexity types to the locaterequest ticket based at least in part on the one or more informationelements.

Another embodiment is directed to an apparatus for assessing a level ofrisk associated with one or more locate operations requested in a locaterequest ticket. The apparatus comprises at least one processorprogrammed to extract one or more information elements from the locaterequest ticket, and determine a risk value associated with the locaterequest ticket based at least in part on the one or more informationelements.

Another embodiment is directed to an apparatus for assessing at leastone attribute of a locate and/or marking operation requested in a locaterequest ticket, the locate and/or marking operation comprising detectingand/or marking a presence or an absence of at least one undergroundfacility within a dig area, wherein at least a portion of the dig areais planned to be excavated or disturbed during excavation activities,the apparatus comprising: at least one communication interface; at leastone memory to store processor-executable instructions; and at least oneprocessor communicatively coupled to the at least one memory and the atleast one communication interface, wherein, upon execution of theprocessor-executable instructions, the at least one processor: A)obtains ticket information from the locate request ticket at least inpart by parsing the locate request ticket; B) applies one or morebusiness rules to at least some of the ticket information to generate atleast one ticket assessment outcome for the at least one attribute; andC) controls the at least one communication interface to transmit, and/orcontrols the at least one memory to store, the at least one ticketassessment outcome so as to facilitate clearing the locate requestticket and/or dispatching at least one locate technician to perform thelocate and/or marking operation, based at least in part on the at leastone ticket assessment outcome.

Another embodiment is directed to a method, performed in a systemcomprising at least one processor, at least one memory, and at least onecommunication interface, for assessing at least one attribute of alocate and/or marking operation requested in a locate request ticket,the locate and/or marking operation comprising detecting and/or markinga presence or an absence of at least one underground facility within adig area, wherein at least a portion of the dig area is planned to beexcavated or disturbed during excavation activities, the methodcomprising: A) obtaining ticket information from the locate requestticket at least in part by parsing, via the at least one processor, thelocate request ticket; B) applying one or more business rules to atleast some of the ticket information, via the at least one processor, togenerate at least one ticket assessment outcome for the at least oneattribute; and C) transmitting via the at least one communicationinterface, and/or storing in the at least one memory, the at least oneticket assessment outcome so as to facilitate clearing the locaterequest ticket and/or dispatching at least one locate technician toperform the locate and/or marking operation, based at least in part onthe at least one ticket assessment outcome.

Another embodiment is directed to at least one non-transitorycomputer-readable storage medium encoded with at least one programincluding processor-executable instructions that, when executed by aprocessor, perform a method for assessing at least one attribute of alocate and/or marking operation requested in a locate request ticket,the locate and/or marking operation comprising detecting and/or markinga presence or an absence of at least one underground facility within adig area, wherein at least a portion of the dig area is planned to beexcavated or disturbed during excavation activities, the methodcomprising: A) obtaining ticket information from the locate requestticket at least in part by parsing the locate request ticket; B)applying one or more business rules to at least some of the ticketinformation to generate at least one ticket assessment outcome for theat least one attribute; and C) transmitting and/or storing the at leastone ticket assessment outcome so as to facilitate clearing the locaterequest ticket and/or dispatching at least one locate technician toperform the locate and/or marking operation, based at least in part onthe at least one ticket assessment outcome.

Another embodiment is directed to an apparatus for assessing complexityof a locate and/or marking operation requested in a locate requestticket, the locate and/or marking operation comprising detecting and/ormarking a presence or an absence of at least one underground facilitywithin a dig area, wherein at least a portion of the dig area is plannedto be excavated or disturbed during excavation activities, the apparatuscomprising: at least one communication interface; at least one memory tostore processor-executable instructions; and at least one processorcommunicatively coupled to the at least one memory and the at least onecommunication interface, wherein, upon execution of theprocessor-executable instructions, the at least one processor: A)analyzes ticket information obtained from the locate request ticket; B)assigns at least one complexity designation to the locate request ticketbased at least in part on A); and C) controls the at least onecommunication interface to transmit, and/or controls the at least onememory to store, the at least one complexity designation so as tofacilitate clearing the locate request ticket and/or dispatching atleast one locate technician to perform the locate and/or markingoperation, based at least in part on the at least one complexitydesignation.

Another embodiment is directed to a method, performed in a systemcomprising at least one processor, at least one memory, and at least onecommunication interface, for assessing complexity of a locate and/ormarking operation requested in a locate request ticket, the locateand/or marking operation comprising detecting and/or marking a presenceor an absence of at least one underground facility within a dig area,wherein at least a portion of the dig area is planned to be excavated ordisturbed during excavation activities, the method comprising: A)analyzing, via the at least one processor, ticket information obtainedfrom the locate request ticket; B) assigning, via the at least oneprocessor, at least one complexity designation to the locate requestticket based at least in part on A); and C) transmitting via the atleast one communication interface, and/or storing in the at least onememory, the at least one complexity designation so as to facilitateclearing the locate request ticket and/or dispatching at least onelocate technician to perform the locate and/or marking operation, basedat least in part on the at least one complexity designation.

Another embodiment is directed to at least one non-transitorycomputer-readable storage medium encoded with at least one programincluding processor-executable instructions that, when executed by aprocessor, perform a method for assessing complexity of a locate and/ormarking operation requested in a locate request ticket, the locateand/or marking operation comprising detecting and/or marking a presenceor an absence of at least one underground facility within a dig area,wherein at least a portion of the dig area is planned to be excavated ordisturbed during excavation activities, the method comprising: A)analyzing ticket information obtained from the locate request ticket; B)assigning at least one complexity designation to the locate requestticket based at least in part on A); and C) transmitting and/or storingthe at least one complexity designation so as to facilitate clearing thelocate request ticket and/or dispatching at least one locate technicianto perform the locate and/or marking operation, based at least in parton the at least one complexity designation.

Another embodiment is directed to an apparatus for assessing riskassociated with a locate and/or marking operation requested in a locaterequest ticket, the locate and/or marking operation comprising detectingand/or marking a presence or an absence of at least one undergroundfacility within a dig area, wherein at least a portion of the dig areais planned to be excavated or disturbed during excavation activities,the apparatus comprising: at least one communication interface; at leastone memory to store processor-executable instructions; and at least oneprocessor communicatively coupled to the at least one memory and the atleast one communication interface, wherein, upon execution of theprocessor-executable instructions, the at least one processor: A)analyzes ticket information obtained from the locate request ticket; B)assigns at least one risk designation to the locate request ticket basedat least in part on A); and C) controls the at least one communicationinterface to transmit, and/or controls the at least one memory to store,the at least one risk designation so as to facilitate clearing thelocate request ticket and/or dispatching at least one locate technicianto perform the locate and/or marking operation, based at least in parton the at least one risk designation.

Another embodiment is directed to a method, performed in a systemcomprising at least one processor, at least one memory, and at least onecommunication interface, for assessing risk associated with a locateand/or marking operation requested in a locate request ticket, thelocate and/or marking operation comprising detecting and/or marking apresence or an absence of at least one underground facility within a digarea, wherein at least a portion of the dig area is planned to beexcavated or disturbed during excavation activities, the methodcomprising: A) analyzing ticket information obtained from the locaterequest ticket; B) assigning at least one risk designation to the locaterequest ticket based at least in part on A); and C) transmitting and/orstoring the at least one risk designation so as to facilitate clearingthe locate request ticket and/or dispatching at least one locatetechnician to perform the locate and/or marking operation, based atleast in part on the at least one risk designation.

Another embodiment is directed to at least one non-transitorycomputer-readable storage medium encoded with at least one programincluding processor-executable instructions that, when executed by aprocessor, perform a method for assessing risk associated with a locateand/or marking operation requested in a locate request ticket, thelocate and/or marking operation comprising detecting and/or marking apresence or an absence of at least one underground facility within a digarea, wherein at least a portion of the dig area is planned to beexcavated or disturbed during excavation activities, the methodcomprising: A) analyzing ticket information obtained from the locaterequest ticket; B) assigning at least one risk designation to the locaterequest ticket based at least in part on A); and C) transmitting and/orstoring the at least one risk designation so as to facilitate clearingthe locate request ticket and/or dispatching at least one locatetechnician to perform the locate and/or marking operation, based atleast in part on the at least one risk designation.

Another embodiment is directed to an apparatus for assessing a locateand/or marking operation requested in a locate request ticket, thelocate and/or marking operation comprising detecting and/or marking apresence or an absence of at least one underground facility within a digarea, wherein at least a portion of the dig area is planned to beexcavated or disturbed during excavation activities, the apparatuscomprising: at least one communication interface; at least one memory tostore processor-executable instructions; and at least one processorcommunicatively coupled to the at least one memory and the at least onecommunication interface, wherein, upon execution of theprocessor-executable instructions, the at least one processor: A) in afirst stage of assessment, produces a first assessment outcome at leastin part by analyzing at least some ticket information obtained from thelocate request ticket; B) in a second stage of assessment, produces asecond assessment outcome based at least in part on the first assessmentoutcome; and C) controls the at least one communication interface totransmit, and/or controls the at least one memory to store, at least oneof the first assessment outcome and the second assessment outcome so asto facilitate clearing the locate request ticket and/or dispatching atleast one locate technician to perform the locate and/or markingoperation.

Another embodiment is directed to a method, performed in a systemcomprising at least one processor, at least one communication interface,and at least one memory, for assessing a locate and/or marking operationrequested in a locate request ticket, the locate and/or markingoperation comprising detecting and/or marking a presence or an absenceof at least one underground facility within a dig area, wherein at leasta portion of the dig area is planned to be excavated or disturbed duringexcavation activities, the method comprising: A) in a first stage ofassessment performed by the at least one processor, producing a firstassessment outcome at least in part by analyzing at least some ticketinformation obtained from the locate request ticket; B) in a secondstage of assessment performed by the at least one processor, producing asecond assessment outcome based at least in part on the first assessmentoutcome; and C) transmitting via the at least one communicationinterface, and/or storing in the at least one memory, at least one ofthe first assessment outcome and the second assessment outcome so as tofacilitate clearing the locate request ticket and/or dispatching atleast one locate technician to perform the locate and/or markingoperation.

Another embodiment is directed to at least one non-transitorycomputer-readable storage medium encoded with at least one programincluding processor-executable instructions that, when executed by aprocessor, perform a method for assessing a locate and/or markingoperation requested in a locate request ticket, the locate and/ormarking operation comprising detecting and/or marking a presence or anabsence of at least one underground facility within a dig area, whereinat least a portion of the dig area is planned to be excavated ordisturbed during excavation activities, the method comprising: A) in afirst stage of assessment, producing a first assessment outcome at leastin part by analyzing at least some ticket information obtained from thelocate request ticket; and B) in a second stage of assessment, producinga second assessment outcome based at least in part on the firstassessment outcome.

Another embodiment is directed to an apparatus for managing informationassets used for assessing locate and/or marking operations requested inlocate request tickets, each locate and/or marking operation comprisingdetecting and/or marking a presence or an absence of at least oneunderground facility within a dig area, wherein at least a portion ofthe dig area is planned to be excavated or disturbed during excavationactivities, the apparatus comprising: at least one communicationinterface; at least one memory to store processor-executableinstructions; and at least one processor communicatively coupled to theat least one memory and the at least one communication interface,wherein, upon execution of the processor-executable instructions, the atleast one processor: A) analyzes a record of a completed locate and/ormarking operation; and B) updates, based at least in part on A), atleast one information asset used for assessing locate and/or markingoperations requested in locate request tickets. In one aspect, the atleast one information asset comprises at least one business rule to beapplied to ticket information to obtain one or more ticket assessmentoutcomes.

Another embodiment is directed to a method, performed in a systemcomprising at least one processor and at least one memory, for managinginformation assets used for assessing locate and/or marking operationsrequested in locate request tickets, each locate and/or markingoperation comprising detecting and/or marking a presence or an absenceof at least one underground facility within a dig area, wherein at leasta portion of the dig area is planned to be excavated or disturbed duringexcavation activities, the method comprising: A) analyzing, via the atleast one processor, a record, stored in the at least one memory, of acompleted locate and/or marking operation; and B) updating, based atleast in part on A), at least one information asset stored in the atleast one memory and used for assessing locate and/or marking operationsrequested in locate request tickets. In one aspect, the at least oneinformation asset comprises at least one business rule to be applied toticket information to obtain one or more ticket assessment outcomes.

Another embodiment is directed to at least one non-transitorycomputer-readable storage medium encoded with at least one programincluding processor-executable instructions that, when executed by aprocessor, perform a method for managing information assets used forassessing locate and/or marking operations requested in locate requesttickets, each locate and/or marking operation comprising detectingand/or marking a presence or an absence of at least one undergroundfacility within a dig area, wherein at least a portion of the dig areais planned to be excavated or disturbed during excavation activities,the method comprising: A) analyzing a record of a completed locateand/or marking operation; and B) updating, based at least in part on A),at least one information asset used for assessing locate and/or markingoperations requested in locate request tickets. In one aspect, the atleast one information asset comprises at least one business rule to beapplied to ticket information to obtain one or more ticket assessmentoutcomes.

For purposes of the present disclosure, the term “dig area” refers to aspecified area of a work site within in which there is a plan to disturbthe ground (e.g., excavate, dig holes and/or trenches, bore, etc.), andbeyond which there is no plan to excavate in the immediate surroundings.Thus, the metes and bounds of a dig area are intended to providespecificity as to where some disturbance to the ground is planned at agiven work site. It should be appreciated that a given work site mayinclude multiple dig areas.

The term “facility” refers to one or more lines, cables, fibers,conduits, transmitters, receivers, or other physical objects orstructures capable of or used for carrying, transmitting, receiving,storing, and providing utilities, energy, data, substances, and/orservices, and/or any combination thereof. The term “undergroundfacility” means any facility beneath the surface of the ground. Examplesof facilities include, but are not limited to, oil, gas, water, sewer,power, telephone, data transmission, cable television (TV), and/orinternet services.

The term “locate device” refers to any apparatus and/or device fordetecting and/or inferring the presence or absence of any facility,including without limitation, any underground facility.

The term “marking device” refers to any apparatus, mechanism, or otherdevice that employs a marking dispenser for causing a marking materialand/or marking object to be dispensed, or any apparatus, mechanism, orother device for electronically indicating (e.g., logging in memory) alocation, such as a location of an underground facility. Additionally,the term “marking dispenser” refers to any apparatus, mechanism, orother device for dispensing and/or otherwise using, separately or incombination, a marking material and/or a marking object. An example of amarking dispenser may include, but is not limited to, a pressurized canof marking paint. The term “marking material” means any material,substance, compound, and/or element, used or which may be usedseparately or in combination to mark, signify, and/or indicate. Examplesof marking materials may include, but are not limited to, paint, chalk,dye, and/or iron. The term “marking object” means any object and/orobjects used or which may be used separately or in combination to mark,signify, and/or indicate. Examples of marking objects may include, butare not limited to, a flag, a dart, and arrow, and/or an RFID markingball. It is contemplated that marking material may include markingobjects. It is further contemplated that the terms “marking materials”or “marking objects” may be used interchangeably in accordance with thepresent disclosure.

The term “locate mark” means any mark, sign, and/or object employed toindicate the presence or absence of any underground facility. Examplesof locate marks may include, but are not limited to, marks made withmarking materials, marking objects, global positioning or otherinformation, and/or any other means. Locate marks may be represented inany form including, without limitation, physical, visible, electronic,and/or any combination thereof.

The terms “locate and marking operation,” “locate operation,” and“locate” are used interchangeably and refer to any activity to detect,infer, and/or mark the presence or absence of an underground facility.In some instances, the term “marking operation” is used to morespecifically refer to that portion of a locate operation in which amarking material and/or one or more marking objects is/are employed tomark a presence or an absence of one or more underground facilities. Theterm “locate technician” refers to an individual performing a locateoperation. A locate operation often is specified in connection with adig area, at least a portion of which may be excavated or otherwisedisturbed during excavation activities.

The terms “locate request” and “excavation notice” are usedinterchangeably to refer to any communication to request a locate andmarking operation. The term “locate request ticket” (or simply “ticket”)refers to any communication or instruction to perform a locateoperation. A ticket might specify, for example, the address ordescription of a dig area to be marked, the day and/or time that the digarea is to be marked, and/or whether the user is to mark the excavationarea for certain gas, water, sewer, power, telephone, cable television,and/or some other underground facility. The term “historical ticket”refers to past tickets that have been completed.

It should be appreciated that all combinations of the foregoing conceptsand additional concepts discussed in greater detail below (provided suchconcepts are not mutually inconsistent) are contemplated as being partof the inventive subject matter disclosed herein. In particular, allcombinations of claimed subject matter appearing at the end of thisdisclosure are contemplated as being part of the inventive subjectmatter disclosed herein. It should also be appreciated that terminologyexplicitly employed herein that also may appear in any disclosureincorporated by reference should be accorded a meaning most consistentwith the particular concepts disclosed herein.

BRIEF DESCRIPTION OF THE DRAWINGS

The drawings are not necessarily to scale, emphasis instead generallybeing placed upon illustrating the principles of the invention.

FIG. 1 shows an example in which a locate operation is initiated as aresult of an excavator serving an excavation notice to a one-callcenter.

FIG. 2 shows an example of a ticket management system, according to someembodiments of the present disclosure, comprising a number of softwarecomponents for performing various functions, such as parsing incominglocate request tickets, assessing parsed tickets according toappropriate business rules, and scheduling and dispatching locatetechnicians to perform locate operations.

FIG. 2A shows an illustrative implementation of a ticket assessmentengine comprising a network of ticket assessment modules arranged inmultiple stages.

FIG. 3 shows an example of a locate request ticket that may be receivedby a ticket management system, according to some embodiments of thepresent disclosure.

FIG. 4 shows an example of a virtual white lines (VWL) image associatedwith a ticket received by a ticket management system, according to someembodiments of the present disclosure.

FIG. 5 shows an illustrative process that may be performed by a ticketparsing application to convert an incoming locate request ticket into aparsed ticket, according to some embodiments of the present disclosure.

FIG. 6 shows an example in which a ticket assessment engine accesses oneor more stored images that have been processed by a geographicinformation system, according to some embodiments of the presentdisclosure.

FIG. 7 shows an example of a facilities map with an overlaid VWL image,according to some embodiments of the present disclosure.

FIG. 8 shows an illustrative set of lookup tables that may be used by aticket assessment engine, according to some embodiments of the presentdisclosure.

FIG. 9 shows an illustrative process that may be performed by a ticketassessment engine to selecting the best available location informationand refine the location information when necessary, according to someembodiments of the present disclosure.

FIG. 10 illustrates an exemplary method for refining locationinformation, according to some embodiments of the present disclosure.

FIG. 11 shows an illustrative process that may be performed by a ticketassessment engine to assess the scope of a locate request ticket,according to some embodiments of the present disclosure.

FIG. 12 shows an illustrative process that may be performed by a ticketassessment engine to assess the complexity of a locate request ticket,according to some embodiments of the present disclosure.

FIG. 13 shows an illustrative process that may be performed by a ticketassessment engine to estimate the duration of a locate request ticket,according to some embodiments of the present disclosure.

FIG. 14 shows an illustrative process that may be performed by a ticketassessment engine to compute a risk measurement associated with a locaterequest ticket, according to some embodiments of the present disclosure.

FIG. 15 shows an illustrative process that may be performed by a ticketassessment engine to compute an estimated value for a locate requestticket, according to some embodiments of the present disclosure.

FIG. 16A shows an illustrative process that may be performed by a ticketassessment engine to identify one or more required and/or recommendedpieces of equipment for performing a requested locate operation,according to some embodiments of the present disclosure.

FIG. 16B shows an illustrative process that may be performed by a ticketassessment engine to identify one or more requirements and/orrecommendations for selecting a suitable technician to perform arequested locate operation, according to some embodiments of the presentdisclosure.

FIG. 17 shows an illustrative example of a multi-stage ticket assessmentengine having a network of assessment modules.

FIG. 18 shows an example of a work order that may be created from anincoming locate request ticket, according to some embodiments of thepresent disclosure.

FIG. 19 shows an illustrative computer that may be used for improvinginformation management, dissemination, and utilization in the locateindustry and other field service industries, according to someembodiments of the present disclosure.

DETAILED DESCRIPTION I. Overview

Various embodiments described herein relate to systems, methods andapparatus for improved information management, dissemination andutilization in field service operations in which mobile technicians aredispatched in response to service requests. In particular, someexemplary embodiments relate to systems, methods and apparatus forautomatically and intelligently assessing locate request tickets toprovide information that can be used to improve activity scheduling,resource allocation, quality control, and/or regulatory compliance.While the particular example of locate request tickets is providedherein primarily for purposes of illustration, it should be appreciatedthat the inventive concepts described herein may be more generallyapplicable to other types of field service operations.

As discussed above, the inventors have appreciated that there is a lackof an established data standard for use when sharing information amongvarious entities in the locate industry, such as excavators, one-callcenters, facility owners and locate service providers. As a result, theavailability and consistency of data may not be always guaranteed.Accordingly, in some exemplary embodiments, a ticket management systemis provided that associates a level of confidence with at least someinput data to indicate how reliable the data is. For example, a level ofconfidence may be assigned to a data unit as it enters the ticket managesystem, so that the propagation of unreliable information may belimited. In some embodiments, confidence levels may be used to resolveconflicts, so that information from a more trust-worthy source may bechosen over information from a less trust-worthy source. Additionally,multiple related pieces of information may be compared, and a confidencelevel may be increased when the related pieces of information areconsistent with each other.

In some further embodiments, a ticket management system is provided thatincludes a ticket assessment engine for analyzing incoming locaterequest tickets. The ticket assessment engine may be programmed toderive useful information that is not directly available from thetickets themselves. A number of different types of assessments may beperformed, including, but not limited to, those listed below.Furthermore, the different types of assessments may be performed in oneor more stages, where an assessment outcome from one stage may influencean assessment outcome at a subsequent stage.

-   -   Location: In location assessment, various locations of interest        may be derived and/or estimated, such as a location of a work        site in which excavation activities are planned. In some        instances, insufficient location information may be provided in        a locate request ticket. For example, a location description may        be vague or ambiguous (e.g., a street name without any house        numbers). In other instances, multiple conflicting pieces of        location information may be given (e.g., a street address and a        pair of lat/long coordinates that do not match). In these        situations, additional analysis may be needed to ascertain the        location of the work site. Other examples of location        information that may be assessed include a location of one or        more landmarks at or near the work site, a location of one or        more dig area indicators provided on a virtual white lines (VWL)        image, and the like.    -   Scope: In scope assessment, any descriptive information        regarding a requested locate operation may be analyzed from        incoming locate request tickets, such as information describing        the extent and/or nature of the requested work. For example, the        size of a dig area, as measured in length or in area, may be        indicative of the scope of a requested locate operation. The        depth of excavation and the number of different facilities to be        located may also be relevant.    -   Complexity: Complexity assessment may identify one or more        aspects of a requested locate operation that may influence a        manner in which the locate operation is to be conducted. For        example, a locate operation may be classified as high complexity        when a high profile facility asset (e.g., gas pipes and/or        fiber-optic communication cables) is involved or when the work        site is in a restricted access area (e.g., a military base or        gated community). Such a classification may be used, for        example, to determine whether a highly skilled technician and/or        particular/special equipment may be required, and/or whether a        delay in completing the locate operation is likely.    -   Time: Various time-related aspects of a requested locate        operation may be assessed, such as a deadline by which the        locate operation must be completed and/or an expected duration        (e.g., an expected amount of time needed to complete the locate        operation). In some situations, the expected duration for a        requested locate operation may be determined based on its        estimated scope (e.g., the number and types of different        facilities involved) and/or complexity (e.g., delays due to        access restrictions, special skills and/or equipment required,        etc.).    -   Risk: Risk assessment may include estimating a measure of        damages in an event of an accident (e.g., when underground        facilities are damaged during excavation due to an improperly or        inaccurately performed locate and/or marking operation).        Examples of damages include, but are not limited to, economic        losses, damages to property, environmental damages, and/or        personal injuries. Certain intangible losses may also be taken        into account, such as loss of customer satisfaction. In some        embodiments, a locate service provider may wish to assess a        level of potential liability for damages in an accident where        the locate service provider is at fault (e.g., failing to        complete a locate operation by a required deadline or        inadequately performing a location operation). For example, a        locate operation involving one or more main utility lines (e.g.,        water mains serving an entire neighborhood) may be considered        high risk, because an accident involving a main utility line may        expose the locate service provider to a large range of damages.        By contrast, a locate operation involving only service lines        (e.g., utility lines leading to a customer's premise) may be        considered low risk, because the potential scope of damages may        be relatively small in an accident involving a service line.    -   Value: Value assessment may be performed according to different        measures of value. For instance, value assessment may be        performed from the perspective of a locate service provider        based on business value created by performing a locate        operation. In some embodiments, such business value may simply        be the revenue collected for the locate operation. In other        embodiments, a measure of net profit may be used, where various        operating costs may be subtracted from the revenue. For example,        a measure of profit may take into account information from one        or more contracts established between a locate service provider        and a facilities owner (or some other entity contracting with        the locate service provider to perform locate operations).        Examples of contractual information include, but are not limited        to, contractual provisions specifying bonuses and/or penalties        for certain tickets. In some further embodiments, a more        sophisticated measure such as value at risk may be used.    -   Resource: Resource assessment may include identifying one or        more resources (e.g., equipment and/or personnel) needed to        adequately perform a requested locate operation. In some        embodiments, resource assessment may identify a personnel skill        level or certification required to perform a locate operation.        For example, in some jurisdictions, only a technician with gas        certification may be dispatched to perform a locate operation        involving gas pipes. In another example, personnel skill level        may encompass both long term measurements, such as years of        experience, and short term measurement, such as recent        performance evaluations. In some further embodiments, resource        assessment may identify one or more tools and/or pieces of        equipment required or recommended for a locate operation. For        example, if a locate request ticket indicates that one or more        gas facilities are to be located, a gas detection tool may be        required or recommended. In some instances, one or more        contracts established between a locate service provider and a        facilities owner (or some other entity contracting with the        locate service provider to perform locate operations) may        specify particular tools/equipment requirements for some types        of locate operations.

The inventors have appreciated that the assessment outcomes provided bya ticket assessment engine may be used to improve various aspects of thebusiness operations of a locate service provider, such activityscheduling, resource allocation, quality control, and/or regulatorycompliance. In some embodiments, the ticket assessment engine may beprogrammed to provide an estimated measurement, ranking, score,classification and/or some other suitable value for each of theassessment targets listed above, or any other desirable assessmenttargets. These outcomes may then be input into one or more othercomponents of the ticket management system, for example, an activityscheduling application, a ticket review application for quality controland training, and/or a customer billing application.

The ticket assessment engine may access various information sources inorder to produce the desired assessment outcomes. For example, theticket assessment engine may make use of facility plats available fromthe facility owners to determine whether certain geographical areasshould be classified as high risk or high complexity areas. As anotherexample, the ticket assessment engine may access a database containingpast damage reports to determine whether a given excavator has a historyof frequent and/or costly damages. As yet another example, the ticketassessment engine may access a database containing information regardingpreviously completed tickets to search for notes and/or remarksregarding a given geographical location.

The inventors have further appreciated that various types of ticketassessment may be carried out by an entity other than a locate serviceprovider, such as a facilities owner, an excavator, a one-call center, acommunity (e.g., city, town, village, and/or other form of municipality)and/or an insurance company. These entities may perform ticketassessment based on their own interests and concerns. For instance, inassessing potential damages in an event of an accident, a facilitiesowner may take into account loss of customer satisfaction due to serviceinterruption, which may in turn lead to economic losses for thefacilities owner (e.g., customer canceling service contract). As anotherexample, a facilities owner may assess the complexity of a requestedlocate and/or marking operation and determine whether it may bedesirable to dispatch its own personnel to monitor the operation. Insome instances, the facilities owner may even decide to dispatch its ownpersonnel to perform the requested operation, instead of a locatetechnician dispatched by a locate service provider. As yet anotherexample, a facilities owner or regulatory body may use ticket assessmentto identify high risk locate and/or marking operations that may requireauditing prior to excavation, to ensure that the locate serviceprovider's technicians have adequately performed the operations.

Following below are more detailed descriptions of various conceptsrelated to, and embodiments of, inventive systems, methods and apparatusfor improved information management, dissemination and utilization infield service applications and, in particular, for assessing locaterequest tickets. It should be appreciated that various conceptsintroduced above and discussed in greater detail below may beimplemented in any of numerous ways, as the disclosed concepts are notlimited to any particular manner of implementation. For instance, thepresent disclosure is not limited to the particular arrangements ofcomponents shown in the various figures, as other arrangements may alsobe suitable. Such examples of specific implementations and applicationsare provided primarily for illustrative purposes.

Generic terms such as “engine,” “application” or “module” may be usedherein when referring to one or more of software components of a ticketmanagement system. Such terms should not be interpreted as beinglimiting in any way. Also, each of the software components describedherein may be implemented in any suitable way, for example, asprocessor-executable instructions stored in at least one physicalstorage device (e.g., a non-volatile memory device and/or a volatilememory device) of a general purpose computer or some other suitablehardware system. The general purpose computer or hardware system maycomprise at least one hardware processor for executing the instructionsstored in the physical storage device, and may further comprise at leastone input/output (I/O) interface for receiving inputs from input sourcesor devices and for sending outputs to output recipients or devices. Insome embodiments, the hardware processor on which a software componentexecutes may be in a mobile or portable device, such as a mobiletelephone, personal digital assistant, a marking device (e.g., for spraypainting lines or other marks on the ground), or any other type ofmobile or portable device.

II. System Architecture and Components

FIG. 2 shows an example of a ticket management system 200 comprising anumber of software components for performing various functions, such asparsing incoming locate request tickets, assessing parsed ticketsaccording to appropriate business rules, and scheduling and dispatchinglocate technicians to perform locate operations. Generally, the ticketmanagement system 210 may be a management software application run by alocate service provider, such as the locate service provider 130 shownin FIG. 1, although this is not required.

In the embodiment shown in FIG. 2, the ticket management system 200receives locate request tickets 205 from one or more suitable sources,such as the one-call center 120 shown in FIG. 1. Each ticket typicallyincludes one or more text strings describing various parameters of therequested locate operation, such as time, location and types offacilities. In some instances, one or more images depicting the worksite and/or dig area may also be attached to the ticket. For purposes ofthe present disclosure, “ticket information” refers generally to anyinformation included in or derived from locate request tickets (e.g., asissued by a one-call center).

Depending on the originating one-call centers, different types ofinformation may be stored in the text portions of the tickets 205 indifferent formats. Therefore, a ticket parser 210 may be provided, whichmay be programmed to recognize an origin of a ticket 205 and perform theparsing accordingly to output a parsed ticket 215. The parsed ticket 215may be created according to a standardized ticket format, which may beany suitable set of rules or conventions for representing and organizingdata, designed to facilitate efficient handling of data by varioussoftware components. For example, the standardized format may be anExtensible Markup Language (XML) format. Further details regardingticket parsing are described below in connection with FIG. 5.

In the embodiment shown in FIG. 2, ticket information, which may includeone or more of the original ticket 205, the parsed ticket 215, and anyimages of the work site and/or dig area that may have been attached toor otherwise included with the ticket 205, is stored in a ticketdatabase 220. The ticket database 220 may be any substantiallypersistent storage of data, for example, a relational database that iscreated and maintained using a suitable database software. Therelational database may store relationships between excavationcompanies, one-call centers, facility owners, locate service providers,facilities maps, locate request tickets, and the like.

Any stored ticket information, including the parsed ticket 215, alongwith any associated images, may be retrieved from the ticket database220 in a suitable manner and supplied to a ticket assessment engine 230for processing and analysis. In some instances, the ticket assessmentengine 230 may identify one or more prerequisite activities that must becompleted before the requested locate operation can be undertaken. Forexample, the ticket assessment engine 230 may determine, based on thereceived ticket information, that a safety personnel must be dispatchedto ensure that a manhole is clear of any hazardous gases before a locatetechnician may enter the manhole to perform a requested locateoperation, or that a vacuum truck is to be dispatched to dig one or morepotholes before a locate technician can begin a requested locateoperation. Such prerequisite tasks may be performed by different workcrews (e.g., with different equipment and/or skill sets) and may bescheduled separately from the requested locate operation.

As another example, the ticket 205 (and hence ticket information derivedtherefrom) may be related to a so-called “project ticket,” which is arequest for a locate operation that may encompass an appreciably largelinear distance or geographic area, and hence may require a significantnumber of hours to complete (e.g., the work site may be several milesalong a highway, or may include an entire housing development complex).The ticket assessment engine 230 may break up such a project in asuitable manner into multiple work orders (e.g., work orders 235A-C) andassess the ticket information accordingly (e.g., producing separateassessment outcomes for each individual work order). When appropriate,subsequent processing such as scheduling and dispatch may also beperformed on a per work order basis.

In the embodiment shown in FIG. 2, the ticket assessment engine 230applies an appropriate set of business rules 240 to evaluate ticketinformation. For example, there may be different business rules forassessing each of the following aspects: location, scope, complexity,time, risk, value, and/or resource. Exemplary business rules for some ofthese aspects are described in greater detail below in connection withFIGS. 9-16 and Tables 1-26. However, it should be appreciated that thepresent disclosure is not limited to the specific business rulesdiscussed herein. For example, a business rule engine (not shown) may beused to allow business users to dynamically modify existing businessrules and/or define new rules.

As discussed above, ticket assessment implemented by the ticketassessment engine 230 may proceed in one or more stages, where anassessment outcome from one stage may be an input to a subsequent stageof assessment. Accordingly, in some embodiments, the ticket assessmentengine 230 may comprise one or more modules arranged in multiple stages,where each module may assess a different aspect of the requested locateoperation. For instance, in one exemplary embodiment, the ticketassessment engine 230 may comprise multiple modules for assessing,respectively, location, scope, complexity, time, risk, value, and/orresource. Each module may implement a corresponding set of businessrules, such as the business rules shown in Tables 1-26, and differentmodules may implement the corresponding set of business rules atdifferent assessment stages within the engine 230. Examples of a ticketassessment engine 230 based on multiple assessment modules are describedin greater detail below in connection with FIGS. 2A and 19.

In applying the business rules 240 to assess the ticket information, theticket assessment engine 230 may rely on auxiliary input informationsuch as facilities maps, past damage reports, excavator history,traffic, weather, and the like. These pieces of information may beaccessed as needed from an auxiliary information storage 250, which mayinclude one or more databases and/or lookup tables. Examples of varioustypes of auxiliary input information used by the ticket assessmentengine 230 are described in greater detail below in connection withFIGS. 6-8.

In the embodiment shown in FIG. 2, the ticket assessment engine 230provides as an exemplary output one or more work orders 235A-C andpopulates the work order(s) with corresponding “assessment outcomes.” Anassessment outcome may be a numeric value (which may have any of avariety of possible units of measure, or no particular unit of measure,and may or may not be based on some range or scale), one or more symbolsor alpha-character indicators (e.g., Y/N for “yes/no,” T/F for“true/false,” H/M/L for “high,” “medium,” “low,” etc.), and/or one ormore words/phrases. The ticket assessment engine 230 may output one ormore assessment outcomes per ticket analyzed, such that a set ofassessment outcomes are provided per ticket. As noted above in SectionI, exemplary categories of assessment outcomes include, but are notlimited to, scope, complexity, duration, risk, value, and resources. Thepopulated work orders may then be forwarded to any number of componentsin the ticket management system 200. For example, the populated workorders may be forwarded to a scheduling and dispatch application 260,which may allocate an appropriate technician to each work order based onat least some of the assessment outcomes, such as estimated duration,estimated value and/or resource requirements. Alternatively, thepopulated work orders may be stored in a database that can be accessedby one or more components in the ticket management system 200.

It should be appreciated that the ticket assessment engine 230 may beimplemented in any suitable manner, as the present disclosure is notlimited in this respect. In some embodiments, the ticket assessmentengine 230 may be implemented using Windows Workflow Foundation (WF),which is a Microsoft® technology for defining, executing, and managingworkflows. For example, a workflow definition may be loaded forassessment from a .xml file, using rules loaded from a .rules file. Whena new ticket is ready for assessment, a new instance of the workflow maybe instantiated in a new WF thread. At the completion of successfulticket assessment, the assessment runtime may update the system databasewith the calculated output and mark the ticket as ready for scheduling.

The ticket assessment outcomes may be used by the scheduling anddispatch application 260 in any suitable manner, as the presentdisclosure is not limited in this respect. In some embodiments, a valueassessment outcome may be used as a weighting factor. For example, aticket that is assessed as having high value may be weighted toencourage the scheduling and dispatch application 260 to dispatch theticket ahead of other tickets that are assessed as having lower values.A risk assessment outcome may be used in a similar fashion, to encouragethe dispatch of higher risk tickets ahead of lower risk tickets. Thismay provide for more opportunities for review and quality assessment forthe higher risk tickets.

In some further embodiments, a resource assessment outcome may be usedby the scheduling and dispatch application 260 as a constraining factorin assigning technicians and/or equipment to tickets. For example, aticket may be assessed as requiring a gas-certified, skill level 4(GAS/4) locate technician. This may be used as a hard constraint, sothat only locate technicians with GAS/4 or higher certification may beassigned to the ticket. Alternatively, the skill attribute may be usedas a soft constraint, so that the ticket may be assigned to a lesserqualified locate technician only if a locate technician with GAS/4 orhigher certification is not available. In such a situation, appropriatebusiness rules may be implemented by the scheduling and dispatchapplication 260 to determine whether any potential negative effects(such as increased risk, increased duration, and/or decreasedprofitability) are outweighed by the potential benefits of completingthe requested locate operation earlier.

In yet some further embodiments, the scheduling and dispatch application260 may determine, based on one or more ticket assessment outcomes, thatit is unnecessary to dispatch any technician to perform a requestedlocate and/or marking operation. For example, a scope assessment outcomemay indicate a number and/or a type of facilities to be located asrepresented in the locate request ticket. In some instances, amongst thefacilities noted in the ticket, there may be no underground facilitiesimplicated (e.g., because the work site is located in a rural area thathas only aerial power and phone lines and no underground gas pipes); inthis case, the scope assessment outcome may indicate zero facilities ofan underground type. As another example, a risk assessment outcome mayindicate a low risk associated with the requested locate and/or markingoperation (e.g., because all relevant facilities maps suggest that theclosest underground facilities are at least some threshold distance awayfrom a specified dig area). In these and similar situations, the locaterequest ticket may be flagged for an “office clear” (i.e., clearing theticket without dispatching any locate technician to the work site),which may yield a higher profit margin for the locate service providerthan a ticket for which a technician is dispatched. In some embodiments,the office clear may be performed automatically by analyzing the digarea (e.g., its shape, size, and/or location) against one or morerelevant facilities maps. Alternatively, the office clear may beperformed manually or semi-automatically, where a human operator screensthe ticket to confirm that no underground facilities are likely presentin the dig area.

When a technician reports the completion of a work order, the schedulingand dispatch application 260 may forward the work order to a qualitycontrol application 270, along with any activity logs and/or technicianreports. The quality control application 270 may determine whether thework order has been adequately responded to, for example, by checkingthe activity logs to determine whether every facility type listed on thework order is accounted for. The quality control application 270 mayalso be programmed to present a user interface through which humansupervisors may review the completed work order and determine whetherthe technician is in need of additional training in any particular area.Examples of manual, semi-automated and automated quality assessmenttechniques that may be suitable for implementing the quality controlapplication 270 of the ticket management system 200 may be found in oneor more of the following references, each of which is incorporatedherein by reference:

U.S. patent application Ser. No. 12/493,109, filed on Jun. 26, 2009,entitled “Methods and Apparatus for Quality Assessment of a FieldService Operation;”

U.S. patent application Ser. No. 12/557,732, filed on Aug. 7, 2009,entitled “Methods and Apparatus for Quality Assessment of a FieldService Operation Based on Geographic Information;”

U.S. patent application Ser. No. 12/571,356, filed on Sep. 30, 2009,entitled “Methods and Apparatus for Analyzing Locate and MarkingOperations with Respect to Facilities Maps;”

U.S. patent application Ser. No. 12/572,202, filed on Oct. 1, 2009,entitled “Methods and Apparatus for Analyzing Locate and MarkingOperations with Respect to Historical Information;”

U.S. patent application Ser. No. 12/568,087, filed on Sep. 28, 2009,entitled “Methods and Apparatus for Generating an Electronic Record ofEnvironmental Landmarks Based on Marking Device Actuations;”

U.S. patent application Ser. No. 12/572,260, filed on Oct. 1, 2009,entitled “Methods and Apparatus for Analyzing Locate and MarkingOperations with Respect to Environmental Landmarks;” and

U.S. patent application Ser. No. 12/703,809, filed on Apr. 14, 2010,entitled “Marking Apparatus Equipped with Ticket Processing Software forFacilitating Marking Operations, and Associated Methods.”

Because of a high volume of work orders processed by a locate serviceprovider, it may in some situations be infeasible for every work orderto receive a quality assessment, especially one that requires humanreview. Accordingly, in some embodiments, one or more assessmentoutcomes may be used to filter the completed work orders to identifythose work orders that may require specific quality assessment involvinghuman review. For instance, a risk assessment outcome may be used tofilter out low- or medium-risk work orders, so that only high-risk workorders are submitted for human review. In case a numerical measure ofrisk is used, a suitable threshold may be selected to identify high-riskwork orders. Alternatively, a combination of assessment outcomes may beused for filtering. For example, one or more filtering rules may beapplied to any suitable combination of assessment outcomes (e.g.,location, scope, complexity, time, risk, value and/or resource) toidentify candidate work orders for human review. As a more specificexample, a filtering rule may take into account any suitable combinationof the following information: one or more types of facilities to belocated, client identity (e.g., identity of a facilities owner), type ofexcavation to be carried out subsequent to the locate operation,excavator identity, damage history for a geographical area encompassingthe work site, and damage history associated with the client and/orexcavator. Other types of information may also be taken into account, asthe inventive concepts described herein relating to filtering are notlimited to any specific examples of filtering criteria.

The scheduling and dispatch application 260 may also forward thecompleted work order to a billing application 280, which may applyvarious billing rules to calculate a fee to be billed to each customer.For example, the billing application may use the activity logs todetermine the amount of time the technician spent on each facility typeand compute a fee accordingly to be billed to that facility owner.

In some embodiments, the ticket assessment system 200 may furtherinclude a feedback mechanism, such as a backend assessment module 290.As shown in FIG. 2, the backend assessment module 290 may monitorcompleted work orders received from the scheduling and dispatchapplication 260 and send appropriate updates to various other componentsof the ticket management system 200. For example, the backend assessmentmodule 290 may maintain statistical information regarding the completedwork orders and provide the statistical information to a business ruleengine (not shown), which may update the business rules 240 accordingly.Similarly, the backend assessment module 290 may provide updates to someof the historical information stored in the auxiliary informationstorage 250.

In some instances, a work order may be closed by a technician forreasons other than having completed the requested location operation.For example, the technician may be unable to gain access to a work site,or may discover significant discrepancy between the dig area descriptionand the actual dig area. The technician may then close the current workorder and request that a new work order be generated. Upon detectingsuch a situation, the backend assessment module 290 may generate anappropriate new work order, e.g., with more accurate work site and/ordig area information, and submit it to the scheduling and dispatchapplication 260 for re-dispatch.

Additionally, the backend assessment module 290 may be adapted toreceive information from the quality control application 280. Forexample, upon reviewing a completed work order via the quality controlapplication 280, a human supervisor may discover a significant problemand may determine that a re-mark or re-stake operation is necessary.This information may be provided to the backend assessment module 290,which may generate a new work order accordingly and perform appropriateupdates to the information stored in the auxiliary information storage250.

Turning now to FIG. 2A, an illustrative implementation of a ticketassessment engine (e.g., the ticket assessment engine 230 of FIG. 2) isshown, comprising a network of ticket assessment modules arranged inmultiple assessment stages. In this example, there are N differentstages of assessment within the assessment engine, numbered 1 through N.Each stage may include one or more assessment modules (e.g., labeled inFIG. 2A as “Assessment 1-A,” “Assessment 1-B,” “Assessment N-A,” etc.),wherein each module comprises a corresponding set of business rules(e.g., business rules 240 in FIG. 2) that are used to assess variouselements of ticket information. To this end, each module may receive asinput one or more of the following: ticket information 225, auxiliaryinformation 255, (e.g., facilities maps, stored images, historicalrecords, environmental data and/or lookup tables), and/or one or moreassessment outcomes from one or more previous stages of assessment.

For instance, as illustrated in FIG. 2A, a first stage assessment (Stage1 Assessment) may include two modules, Assessment 1-A and Assessment1-B, each receiving ticket information and auxiliary information asinput. Assessment 1-A may produce Outcome 231, which may be fed into aStage 2 Assessment module, Assessment 2-A. Assessment 1-B may produceOutcome 232, which may also be fed into Assessment 2-A. Furthermore,Outcome 232 may be used at an even later stage of assessment, e.g., atAssessment N-A. Further still, Outcome 232 may be output by the ticketassessment engine as a “final” assessment outcome. In this respect,Outcome 231 produced by Assessment 1-A may be an “intermediate”assessment outcome, in that it is used only internally, by otherassessment modules, and is not output by the ticket assessment engine.

In addition to receiving Outcome 231 and Outcome 232, producedrespectively by the modules Assessment 1-A and Assessment 1-B,Assessment 2-A may access other information, such as the ticketinformation 225 input to the ticket assessment engine and/or auxiliaryinformation 255 accessible to the ticket assessment engine. The outputof Assessment 2-A, namely, Outcome 233, may be output by the ticketassessment engine as a final outcome, and may be fed into a later stageassessment module, e.g., Assessment N-A. Finally, Assessment N-A mayproduce Outcome 234 based on inputs from different stages of assessment,e.g., Outcome 232 and Outcome 233.

Although some specific arrangements of assessment modules are shown inFIG. 2A, it should be appreciated that those arrangements are merelyillustrative. Other suitable arrangements may also be used, as thepresent disclosure is not limited in this respect. Also, any suitabletypes of assessment may be implemented by the assessment modules,including, but not limited to, scope, location, complexity, risk, value,time and/or resource. A more specific illustrate example of amulti-stage ticket assessment engine is discussed in greater detailbelow, in connection with FIG. 17.

III. Exemplary Locate Request Ticket

FIG. 3 shows an example of a locate request ticket 300 that may bereceived by the ticket management system 200, for example, via emailfrom the one-call center 120 shown in FIG. 1. The ticket 300 may containvarious pieces of information stored in a number of fields, including:

-   -   Ticket number 302. A ticket type (e.g., new, emergency, re-mark        or survey) may also be indicated    -   Location information 304A (e.g., street address, nearby cross        streets, subdivision, city and/or county) and 304B (e.g.,        lat/long coordinates provided in decimal degrees). Although not        shown, location information may also include coordinates for one        or more dig area indicators on a VWL image associated with the        ticket.    -   Excavation information 306, including reason (e.g., installing        conduit), scope (e.g., 392 feet), depth (e.g., 18-30 inches),        method (e.g., by drill and trencher) and property type (e.g.,        private property).    -   Timing information 308, including scheduled excavation date and        time (e.g., Jan. 6, 2008 at 7:00 a.m.), duration of excavation        (e.g., 3 days), and due date for the corresponding locate        operation request (e.g., Jan. 5, 2008). Although not shown,        timing information may also include a scheduled end date and        time for the excavation activities, and/or a date and time after        which locate marks may expire and a re-mark operation may be        needed.    -   Excavator information 310, including name, address, contact        information such as business and/or mobile phone number, fax        number and email address, and the party who contracted the        excavator (e.g., as indicated in the “Work Being Done For”        field). Although not show, excavator information may also        include a user identifier for the excavator (e.g., a login name        used by the excavator to create the ticket via a one-call        center's web site).    -   One-call center information 312, including the date and time at        which the ticket was created and the customer service        representative who created the ticket. Although not shown,        one-call center information may also include a one-call center        identification (e.g., an alphanumeric identifier for the        one-call center that created the ticket) and/or information        identifying a method of entry for the ticket (e.g., by phone or        email, or via a web site).    -   Member codes 314, indicating the different types of facilities        that need to be located and/or the facilities owners that are        notified of the ticket.

It should be appreciated that the above list of information elements ismerely illustrative, as other combinations of information elements mayalso be suitable. For example, when preparing a locate request ticket, aone-call center may draw a polygon on a map corresponding to the worksite. This polygon may be overlaid onto one or more facilities maps todetermine which types of facilities are implicated. For example, afacility type (or owner) may be indicated on the locate request ticketin the member code section 314 if and only if at least one utility lineof that type (or owner) touches or intersects with the polygon. In someinstances, the one-call center may provide the coordinates for thevertices of the polygon in the locate request ticket, along with otherinformation describing the location and boundaries of the work siteand/or dig area.

As another example, the ticket may include locate instructions providedby an excavator who initiated the ticket, which may be in the form offree text. As yet another example, the ticket may include informationindicating whether the planned excavation activities include any boring(e.g., on a street, driveway and/or sidewalk) and/or blasting. As yetanother example, the ticket may indicate whether a permit has beenobtained for a related construction project (e.g., installing a swimmingpool or building a foundation for a structure).

In some embodiments, one or more images or graphical representations ofthe work site and/or dig area may be attached to the ticket 300. Forinstance, a so-called virtual white lines (VWL) image may be attached,which may contain a digital image of the work site including the digarea (or some other suitable digital data representing the geographiclocation of the dig area) along with electronic annotations delimitingthe dig area.

An example of a VWL image 400 is shown in FIG. 4. As shown, the dig areais indicated on an aerial image by a set of dashed lines 410 forming arectangle. The lines 410 are more generally referred to as “dig areaindicators,” which may be any electronically generated markingsindicating a point, line, path and/or area of the planned excavation.

In some embodiments, the VWL image 400 may be created by the excavatorusing a suitable VWL application (not shown), such as those described inU.S. patent application Ser. No. 12/050,555 and U.S. Provisional PatentApplication No. 61/151,769 and No. 61/151,815, all of which areincorporated by reference herein in their entireties. For example, theexcavator may use the VWL application to obtain an aerial image of ageographical location encompassing the planned dig area and use adrawing tool of the VWL application to add the dig area indicators 410to the aerial image.

IV. Ticket Parsing

As discussed above, locate request tickets originating from differentone-call centers may store information in different formats (e.g.,different one-call centers may use different commercial software togenerate locate request tickets). Therefore, a ticket parsingapplication, such as the ticket parser 210 shown in FIG. 2, may be usedto convert incoming tickets to a standardized format recognized byvarious components within a ticket management system.

FIG. 5 shows an illustrative process 500 that may be performed by aticket parsing application to convert an incoming locate request ticketinto a parsed ticket.

At act 502, the ticket parsing application may identify a source ororigin of an incoming ticket (e.g., a particular one-call center thatgenerated the incoming ticket). This may be accomplished in a number ofdifferent ways. For example, the ticket parsing application may simplysearch the ticket to determine whether the originating one-call centeris identified in the ticket itself. Alternatively, if the ticket isreceived via email, the ticket parsing application may identify theoriginating one-call center by examining the sender's email address. Asyet another example, the ticket parsing application may search theticket for some indication of a geographic area to which the work sitebelongs (e.g., a city or town name) and identify a one-call centerserving that geographic area.

At act 504, the ticket parsing application may retrieve or otherwiseidentify a set of parsing rules corresponding to the one-call centeridentified at act 502. The parsing rules may allow the ticket parsingapplication to detect the locations of various information elementswithin the incoming ticket. In some instances, the information elementsmay be stored in respective fields in the incoming ticket. There may bea fixed ordering among the various fields, and each field may be a textblock (e.g., an alphanumeric character string) of a fixed length. Thus,each field or text block may be found at a corresponding fixed offsetfrom the beginning of the incoming ticket. Alternatively, some of thefields may have variable lengths, and one or more designated markers maybe used to demarcate the end of a field (or the beginning of the nextfield). In that case, the ticket parsing application may locate andprocess the various fields in a sequential fashion.

At acts 506 and 508, the ticket parsing application may identify aninformation element (e.g., a text block) that has not be processed andproceed to extract information from the identified information element.For example, for a text block corresponding to an address field, theticket parsing application may simply copy the entire string from thetext block. Some minor transformations may be performed at act 510, suchas truncating a street name that exceed a predetermined maximum length.More significant transformations may also be performed. For example, theticket parsing application may be programmed to recognize alphanumericcodes and/or abbreviations specific to each one-call center and mapthose codes and/or abbreviations to some suitable standardrepresentations.

At act 512, the ticket parsing application may populate appropriatefields in the parsed ticket with the information obtained at acts 506and 508. Then, at act 514, the ticket parsing application may determinewhether there is at least one unprocessed information element in theincoming ticket. If the determination is positive, the ticket parsingapplication may return to act 506 to identify a next unprocessedinformation element. Otherwise, the ticket parsing application may endthe process 500, and the parsed ticket may be forwarded to a ticketassessment engine for further processing and analysis.

It should be appreciated that the process 500 for parsing an incomingticket is merely illustrative. Depending on the one-call centers' actualpractices, other processes and methods may also be suitable forconverting an incoming locate request ticket to a standardized format.

V. Auxiliary Information Sources

As discussed above in connection with FIG. 2, the ticket assessmentengine 230 may access various types of auxiliary information from theauxiliary information storage 250 in order to produce the desiredassessment outcomes. For example, as shown in FIG. 6, the assessmentengine 230 may retrieve one or more stored images 605 from the auxiliaryinformation storage 250, along with any associated metadata (e.g.,geospatial metadata). As discussed in greater detail below, the storedimages 605 may be created or modified by a geographic information system(GIS) 610 based on one or more input images 615.

For purposes of the present disclosure, an input image 615 may berepresented by any source data that, when processed electronically by asuitable computer system, enables the computer system to display animage on a display device. This source data may be in any of a varietyof suitable computer-readable formats, including PDF, JPG, BMP, GIF, PNGand the like.

In some instances, the source data for an image may be generated byscanning a tangible two-dimensional image source, such as paper orcloth. Alternatively, the source data may be generated by an imageacquisition device as the result of acquiring a “real-world” scene.Examples of an image acquisition device include a digital camera (eitherstill-frame or video), which may generate pixel information as part ofthe source data for an image. An image acquisition device may also be alaser scanning device that scans three-dimensional objects to producecoordinate information in a three-dimensional space.

The following is a non-exhaustive list of exemplary input images (orsource data) using which the GIS 610 may create or modify the storedimages 605.

-   -   Manual “free-hand” paper sketches of a geographic area, which        may include one or more buildings, natural or man-made        landmarks, property boundaries, streets, intersections and/or        public works or facilities such as street lighting, signage,        fire hydrants, mail boxes, parking meters, etc.    -   Various maps indicating surface features and/or extents of        geographical areas, such as street/road maps, topographical        maps, military maps, parcel maps, tax maps, town and county        planning maps, polygon maps maintained by one-call centers        and/or facility owners, virtual maps, etc.    -   Facilities maps illustrating installed underground facilities,        such as gas, power, telephone, cable, fiber optics, water,        sewer, drainage, etc. Street-level features or landmarks (e.g.,        streets, buildings, aboveground facilities, etc.) may also be        indicated in relation to the depicted underground facilities.        Facilities maps may be provided in paper and/or electronic form        and may be maintained by, for example, one or more facility        owners. For example, a gas company may maintain maps of gas        lines, a power company may maintain maps of power lines, and so        on.    -   Architectural, construction and/or engineering drawings and        virtual renditions of a space/geographic area, including “as        built” and/or post-construction drawings.    -   Land surveys, which are plots produced at ground level using        references to fixed points such as the center line of a street        to indicate the metes and bounds of a building, parcel, utility,        roadway, or other object or installation, as well as other        related location data.    -   Photographic renderings/images, including street level,        topographical, satellite, and aerial photographic        renderings/images, any of which may be updated periodically to        capture changes in a given geographic area over time (e.g.,        seasonal changes such as foliage density, which may variably        impact the visibility of some features in the geographic area).    -   A grid (e.g., a pattern of horizontal and vertical lines) used        as a reference to provide representational geographic        information, which may be added as an overlay to an acquired        “real world” scene, a drawing, a map, etc.    -   “Bare” data representing geo-encoded information (e.g. lat/long        coordinates identifying one or more points), which may be used        to construct a virtual image without having captured any        “real-world” scene. Such “bare” data may be in any of a variety        of computer-readable formats, including XML.

In accordance with some embodiments, input images or source data such asthose listed above may be analyzed and/or manipulated by the GIS 610shown in FIG. 6. For example, the GIS 610 may be programmed to “geotag”an input image by associating geospatial metadata with features in theinput image. The geospatial metadata may include any suitablecombination of lat/long coordinates, altitude, bearing, place names,etc. As another example, the GIS 610 may be programmed to create acomputer-aided design (CAD) drawing showing aboveground and/orunderground facilities installed in a geographic area, and to associategeospatial metadata with at least some of the facilities shown on thedrawing. As yet another example, the GIS 610 may be programmed to aligntwo geotagged images, for example, by scaling one or both of the imagesand aligning one or more reference points. This process is sometimesreferred to as “georeferencing,” and may be useful in combining one ormore facilities maps showing different types of facilities installed inthe same geographic area.

Thus, the GIS 610 may provide a framework for manipulating anddisplaying images in ways that may facilitate a variety oflocation-related analyses. As shown in FIG. 6, the ticket assessmentengine may be adapted to invoke one or more services provided by the GIS610. For example, the assessment engine may submit a geotagged VWL image(e.g., the VWL image 400 shown in FIG. 4) to the GIS 610 and requestthat the dig area indicators (e.g., the dig area indicators 410) beshown on a facilities map. Upon receiving the request, the GIS 610 mayobtain a relevant facilities map, for example, by retrieving one or moreexisting maps from the auxiliary information storage 250 and combingthem if necessary, or by creating a CAD drawing showing all facilitiesknown to be present in the geographic area shown on the VWL image 400.The GIS 610 may then render the dig area indicators 410 as an overlay onthe facilities map based on the geospatial metadata associated with theVWL image and the facilities map. An example of the resulting facilitiesmap 700 with the dig area indicators 410 is shown in FIG. 7.

Images are merely one example of a variety of different types ofinformation that may be used by a ticket assessment engine. Anotherexample is a set of lookup tables, such as the lookup tables 800 shownin FIG. 8. In accordance with some embodiments, the ticket assessmentengine may load one or more of these lookup tables and use them to maplocate operation attributes to intermediate or final assessmentoutcomes. The locate operation attributes may be raw attributes directlyobtained from locate request tickets, or derived attributes assigned bythe ticket assessment engine based on some raw attributes.

In the exemplary embodiment shown in FIG. 8, the lookup tables 800include a complexity lookup table 810, a time lookup table 820, a risklookup table 830, a value lookup table 840 and a resource lookup table850.

The complexity lookup table 810 may be used to assign a suitable measureof complexity to a requested locate operation, and may be indexed with avariety of different locate operation attributes. For example, thecomplexity look up table 810 may map the number of facilities to belocated and/or each individual facility type (e.g., gas, cable,electric, water, etc.) to a suitable complexity level (e.g., high,medium or low). As another example, the complexity lookup table 810 maymap work site details such as high traffic or restricted access tocorresponding complexity reason codes that are recognized by variouscomponents within a ticket management system (e.g., the ticketmanagement system 200 shown in FIG. 2).

Similar to the complexity lookup table 810, the time lookup table 820and the risk lookup table 830 may be used, respectively, to assign anestimated duration and a suitable measure of risk to a requested locateoperation. For example, the time look up table 820 may map eachindividual facility type (e.g., gas, cable, electric, water, etc.) to aduration estimate per unit length or unit area, and the risk lookuptable 830 may map each individual facility type to a suitable riskscore. Additionally, the time lookup table 820 and the risk lookup table830 may, respectively, map work site details such as high traffic orrestricted access to corresponding scaling factors for increasing ordecreasing a duration estimate and a risk score.

The value lookup table 840 may be used to associate a value to arequested locate operation. The value may be simply the expected revenueto be collected for the work performed, or some other suitable measureof value such as net profit (e.g., revenue less cost) or value at risk.In some embodiments, the value lookup table 840 may correlate complexitywith value (e.g., mapping high complexity to high value, mediumcomplexity to medium value, and low complexity to low value), where thecomplexity level is determined at least in part using the complexitylookup table 810. In some further embodiments, the value look up table840 may map each individual facility type (e.g., gas, cable, electric,water, etc.) to a value estimate, which may be a flat rate or a rate perunit length. In yet some further embodiments, the value lookup table 840may map ticket types (e.g., emergency, short notice, re-mark, etc.) tocorresponding adjustment values for increasing or decreasing a value.For example, extra fees may be collected for an emergency locateoperation, while a re-mark operation may not be billed to a customer ifthe locate service provider is at fault (e.g., the locate serviceprovider did not adequately respond to the locate request ticket duringa first visit, which was already billed to the customer).

The resource lookup table 850 may used to determine any equipmentrequirements and/or technician certification and/or minimum skill levelrequirements for a requested locate operation. For example, locatetechnician skill levels may be ranked from 1-10, with 10 being the mostskilled. The resource lookup table 850 may map high complexity to skilllevels 8-10, medium complexity to skill levels 4-7, low complexity toskill levels 1-3, where the complexity level is determined at least inpart using the complexity lookup table 810. As another example, theresource look up table 850 may map each individual facility type (e.g.,gas, cable, electric, water, etc.) to one or more techniciancertifications (e.g., gas-certified, cable-certified,electric-certified, water-certified, etc.). As yet another example, theresource lookup table 850 may map each individual facilities type (e.g.,gas) to one or more required or recommended tools or pieces of equipment(e.g., a gas detection tool).

It should be appreciated that the set of lookup tables 800 is providedherein for purposes of illustration only. For example, although lookuptables may provide quick access to data, other types of data structuresmay also be used to store the information contents described above.Also, a ticket assessment engine may access other types of informationcontents in addition to, or instead of, those described above. Forexample, in determining a risk level associated with a requested locateoperation, a ticket assessment engine may access historical records ofpreviously completed locate request tickets to determine whether thereis a high concentration of past damage reports within the proximity ofthe currently requested locate operation. A historical record of apreviously completed locate request ticket may also store informationcollected during the corresponding locate and/or marking operation. Forexample, the record may store an actual duration of the operation and/oractual durations of various tasks that are part of the operation. Therecord may further indicate whether an accident occurred duringsubsequent excavation (e.g., whether one or more underground facilitieswere damaged during excavation).

As another example, a ticket assessment engine may access recordspertaining to excavation companies and/or individual excavators. Suchrecords may contain information such as excavation company name andaddress, individual excavator name and address, excavator type (e.g.,pool installer, landscaper, construction company, facility installer,etc), and/or damage history. In some embodiments, a ticket assessmentengine may use the excavator type information and the damage historyinformation to assess the level of risk associated with a currentlyrequested location operation. For example, the ticket assessment enginemay return a high risk classification for a requested locate operationwhen a corresponding excavation company and/or individual excavator hasa significant history of damaging facilities. The ticket assessmentengine may further increase a technician skill level requirement for therequested locate operation, as a way to ensure accurate marking andreduce risk.

VI. Location Assessment

As discussed above, location information provided in a locate requestticket may in some instances be incomplete and/or inaccurate. Forexample, the address for the work site may be vague or ambiguous (e.g.,a street name without any house numbers), or multiple conflicting piecesof location information may be given (e.g., a street address and a pairof lat/long coordinates that do not match). In these situations,additional analysis may be needed to increase the level of confidencethat a locate technician is being dispatched to the correct location.For example, additional location information may be extracted from atextual description of the work site that is included in the ticket,and/or from one or more virtual white lines (VWL) images associated withthe ticket.

FIG. 9 shows an illustrative process 900 that may be performed by aticket assessment engine to selecting the best available locationinformation and refine the location information when necessary.

At act 902, the ticket assessment engine may collect one or more piecesof location information from a locate request ticket (e.g., the parsedticket 215 as shown in FIG. 2). For example, the ticket assessmentengine may extract from the ticket a work site address, coordinates forvertices of a polygon generated by the originating one-call center,and/or any VWL images attached to the ticket. In some instances, theticket may additionally contain portions of free text (e.g., in a“Remarks” field recording an excavator's description of the dig areaand/or the reason for excavation). The ticket assessment engine may beprogrammed to intelligently extract location information from theseportions of free text, for example, by searching for relevant phrasessuch as “next to,” “across from,” “near,” etc. Alternatively, the ticketassessment engine may prompt a human user to read the portions of freetext and manually enter any relevant location information.

At act 904, the ticket assessment engine may select a piece of locationinformation from the multiple pieces of location information collectedat act 902. This selection may be based on levels of confidence, thatis, the ticket assessment engine may select the piece of locationinformation that is deemed the most trustworthy or reliable. In someembodiments, a geotagged VWL image may be considered the most reliableamong all types of location information. As such, it may be selectedwhenever available. If a geotagged VWL image is not available, then acomplete address (e.g., with city, street name and house number) may beselected over other pieces of location information, such as a one-callcenter polygon. If neither a geotagged VWL image nor a complete addressis available, then coordinates for the centroid of a one-call centerpolygon may be computed and reverse-geocoded to obtain an address.

The ticket assessment engine may also perform one or more consistencychecks on the collected location information. For example, the ticketassessment engine may reverse-geocode at least some of the availablecoordinates to determine if the coordinates correspond to a point thatfalls within the city, county, and/or state indicated on the ticket.

At act 906, the ticket assessment engine may determine whether thelocation information selected at act 904 has a sufficiently highconfidence level. If the determination is positive, then the process 900ends and the selected location information may be recorded and usedthroughout the rest of the assessment process carried out by the ticketassessment engine. If the determination is negative, the ticketassessment engine may make a best-effort attempt at refining thelocation information at act 908.

FIG. 10 illustrates an exemplary method for refining locationinformation. In this example, a street name (e.g., “Main Street”) isavailable, but without a house number. A one-call center polygon 1000 isalso available. The ticket assessment engine may programmed to determinethe coordinates for the points 1005A and 1005B, at which Main Streetintersects the one-call center polygon 1000. These coordinates may thenbe reverse-geocoded to obtain an address range on Main Street that fallswithin the one-call center polygon 1000. If the address range issufficiently small, the ticket assessment engine may simply select theaddress range as the prevailing location information. If, however, theaddress range is too large, the ticket assessment engine may narrow itdown by computing the centroid of the one-call center polygon 1000 andselecting one or more addresses 1005C that are closest to the computedcentroid.

It should be appreciated that the various rules and methods describedabove in connection with FIGS. 9 and 10 are merely illustrative, asother rules and methods may also be used to select, verify and/or refinelocation information. Also, the ticket assessment engine may invoke theservices of a geographic information system (e.g., the GIS 610 shown inFIG. 6) to perform any of the computational tasks described above.

VI. Scope Assessment

In assessing the scope of a locate request ticket, a ticket assessmentengine may determine the nature and amount of work to be done inresponse to the ticket. The result of scope assessment may be used in anumber of subsequent assessment processes, such complexity, time, risk,value and/or resource requirements. For example, during scopeassessment, the number and types of facilities to be located may bedetermined or verified, which may in turn be used to determinecomplexity (e.g., whether a high profile facility type is involved),time (e.g., an estimated duration for each facility type), risk (e.g.,whether a high risk facility, such as gas, is involved), value (e.g., anestimated revenue to be collected for each facility type) and/orresource requirements (e.g., certification requirements for eachfacility type).

In some instances, a one-call center may compile some form of ticketscope information and include the information in a locate requestticket. For example, a one-call center may generate a polygon anddetermine, based on the polygon, which facility types are to be listedon the ticket. However, such information from one-call centers may notalways be accurate, and therefore it may be desirable to independentlygenerate and verify ticket scope information.

FIG. 11 shows an illustrative process 1100 that may be performed by aticket assessment engine to assess the scope of a locate request ticket.

At act 1102, the ticket assessment engine may extract various pieces ofinformation from the ticket to determine at least one characteristic ofthe planned dig area (e.g., size, shape and/or boundaries). For example,if a geotagged VWL image is available, the ticket assessment engine maydetermine the dig area boundaries based on the dig area indicators andthe geospatial metadata associated with the VWL image. As discussedabove, the ticket assessment engine may associate a higher level ofconfidence to the VWL image, compared to a polygon generated by theone-call center. Therefore, in some embodiments, the VWL image may beused in lieu of the one-call center polygon in determining ticket scope.

The ticket assessment may also use other types of information during act1102. In some embodiments, the ticket assessment engine may search forscope information in one or more free text portions of the ticket. Forexample, the ticket assessment engine may be programmed to search forkeywords related to landmarks (e.g., sidewalk, playground, etc.) and/ordirections (e.g., north, east, south, west, etc.). If one or morekeywords are found, the ticket assessment engine may prompt a human userto read the free text and enter any additional scope information.

At act 1104, the ticket assessment engine may determine the reason forand/or method of excavation, which may be used to determine otherscope-related parameters such as excavation depth and/or dig area size.

The reason for excavation may sometimes be given explicitly in theticket. For example, as shown in FIG. 3, the ticket 300 may indicateunder the excavation information 306 and the excavator information 310that a conduit is being installed for a telephone company. In othersituations, the reason for excavation may be found in a free textdescription given by the excavator, and the ticket assessment engine maysearch for informative keywords or key phrases in the free textdescription. For example, words such as “pool” and “mailbox” may becommonly used when describing the reason for excavation, and the ticketparsing application may be programmed to recognize these words andextract relevant portions of the free text. In some further situations,the reason for excavation may be inferred based on excavatorinformation. For instance, if the excavator is a plumbing company, thereason for excavation is likely to be installing water and/or sewerlines. On the other hand, if the excavator is a pool contractor, thereason for excavation is likely to be installing a swimming pool.

In some embodiments, the excavation information may indicate a method ofexcavation, which may be helpful in estimating the extent of theexcavation activities. Certain methods of excavation, such as blastingand/or boring, may be more likely to cause accidents compared to othermethods. For example, where blasting is planned, it may be desirable toinclude in the dig area a circular area of a certain radius centered atthe planned location of blasting. As another example, where boring isplanned, it may be desirable to include in the dig area all areas withina certain distance from the planned locations of boring. The particularradius and/or distance may be selected based on a number of differentfactors, e.g., government regulations, contractual obligations,insurance requirements, industry best practices, and/or the locateservice provider's risk tolerance levels.

At act 1106, the ticket assessment engine may determine or verify thenumber and types of facilities to be located. Alternatively, the ticketassessment engine may verify the list of one-call center members (orfacilities owners) who are notified of the ticket. As discussed above,it may be desirable to independently verify this type of information,even though it may be already provided by the one-call center.

The ticket assessment may use a variety of auxiliary information (e.g.,as stored in the auxiliary information storage 250 shown in FIG. 2) indetermining or verifying the number and types of facilities to belocated. For example, the ticket assessment engine may access one ormore facilities maps illustrating installed underground facilities andstreet-level landmarks. In some instances, the facilities maps may begeotagged, which may enable overlaying a polygon or dig area indicatorsonto the facilities maps (e.g., as shown in FIG. 7) to determine whetherone or more items on the facilities maps fall within the dig area or aresufficiently close to the dig area.

Continuing to act 1108, the ticket assessment engine may determine scopeinformation for each individual facility type determined at act 1106.For example, the ticket assessment engine may compare the dig areaboundaries (e.g., as indicated by dig area indicators or a polygon)against a respective facilities map. This may facilitate subsequent timeestimation (e.g., different facility types may have different durationestimates per unit length or unit area). It may also facilitate billingafter the ticket has been completed (e.g., some facility owners may bebilled on a per ticket basis, while other facility owners may be billedper unit of work performed).

Although detailed examples of scope-related analyses are described abovein connection with FIG. 11, it should be appreciated that the inventiveconcepts disclosed herein are not limited to any specificimplementations. For example, to the extent that the analyses areindependent from each other, they may be performed in any suitable order(e.g., not necessarily in the order presented in FIG. 11). As a morespecific example, the determination of excavation reason and/or methodat act 1104 may be carried out prior to, or concurrently with, thedetermination of dig area characteristics at act 1102. Other variationsmay also be possible.

V. Complexity Assessment

In various embodiments, a ticket may be considered more or less complexfor a number of different reasons, such as the number and types offacilities to be located, work site characteristics and/or some othersuitable combination of factors. Therefore, complexity assessment mayvery broadly encompass any types of analysis to categorizes and/orannotate a ticket in such a way that facilitates subsequent handling ofthe ticket. For example, the outcomes of complexity assessment may bepresented in any suitable manner (e.g., using numerical scores and/oruser-defined categories), and may inform any other assessment process,such as time, risk, value or resource requirements. Furthermore,complexity assessment may take into account any suitable inputinformation, such as information directly available from a ticket, orinformation derived based on the ticket and/or other auxiliaryinformation.

FIG. 12 shows an illustrative process 1200 that may be performed by aticket assessment engine to assess the complexity of a locate requestticket, in accordance with some embodiments.

At act 1202, the ticket assessment engine may perform a keyword searchon the ticket to look for any keywords that may trigger a complexitydesignation. For example, service contracts with some facility ownersmay include special requirements for the handling of certain types of“high profile” facilities (e.g., gas pipes and/or fiber optic cables),and a locate service provider may receive higher compensation forcomplying with these special requirements. A locate service provider mayalso have internal regulations designating certain facilities as being“high profile.” This may be done, for example, for risk managementpurposes. Thus, when the ticket assessment engine detects the presenceof one or more high profile facility types (e.g., gas or fiber optic),the ticket may be put into a complexity category of “high profile.”Additionally, one or more reason codes and/or descriptions may be givento indicate why the ticket has been categorized under “high profile.”

In some embodiments, the designation of “high profile” may also takeinto account a location of the work site. For example, althoughtelephone and/or electric facilitates may not ordinarily be considered“high profile,” one or more sections of these facilities may bedesignated as such because they serve a special area, such as a hospitalor military base. (This may be the case even if the work site itself isoutside the special area.) Accordingly, the ticket assessment engine mayuse the work site location in conjunction with one or more facilitiesmaps to determine whether any facilities to be located serve one or morespecial areas. If so, the ticket may be put into the “high profile”category along with an appropriate reason code and/or description.

Continuing with FIG. 12, the ticket assessment engine records, at act1204, the complexity category assigned to the locate request ticketduring act 1202, along with any reason codes and/or descriptions. Thisrecording may be done in any suitable manner that allows the assignedcomplexity category to be later accessed using some informationassociated with the ticket. For example, the ticket assessment enginemay store the assigned category in a database entry that can be indexedusing a ticket serial number. Alternatively, the ticket assessmentengine may insert the assigned complexity category into a work ordercreated for the ticket (e.g., work orders 235A-C shown in FIG. 2).

At act 1206, the ticket assessment may determine whether the work sitefalls within some complexity region. For example, the ticket assessmentengine may access a data storage (e.g., the auxiliary informationstorage 250) to obtain a set of polygons representing, respectively, aset of predetermined complexity regions. Each of the polygons may bespecified by the set of coordinates for its vertices, and may beassociated with a complexity category indicating why the region has beendesignated as a complexity region. A more detailed description of thecomplexity category may also be provided.

The ticket assessment engine may then geocode an address of the worksite and determine whether the resulting coordinates fall within any ofthe complexity regions represented by the polygons. If the coordinatesdo fall within at least one complexity region, the ticket assessmentengine may proceed to act 1208 to store the corresponding complexitycategory and/or complexity category description.

It should be appreciated that the polygons representing complexityregions may be generated in a number of different ways, as the presentdisclosure is not limited in this respect. For example, a geographicalinformation system (e.g., the GIS 610 shown in FIG. 6) may be used toanalyze one or more facilities maps, either alone or in combination, toidentify any geographical area with a high concentration of undergroundfacilities. As another example, some commercially available digital mapdata may contain information delimiting various geographical regions ofinterest, such as highways, railroad tracks, parks, hospitals, militarybases, schools, gated communities, zoning parcels, etc. A geographicalinformation system may be used to automatically assign complexitycategories to some of these regions. The corresponding delimitationinformation may then be extracted from the digital map data and used tocompute polygons.

Additionally, a geographical information system may be adapted to allowa human user to manually define a complexity region. For example, asupervisory personnel may, based on local knowledge, designate a certaingeographic area as a complexity region and provide an appropriatedescription (e.g., the area may be known to have defective tracer wiresalong a certain type of facility, which may increase the difficulty inlocating that type of facility). The geographic information system maypresent a graphic user interface to allow the supervisory personnel toelectronically mark the boundaries of the complexity region.

Returning to FIG. 12, the ticket assessment engine may determine at act1210 whether the work site is in the proximity of a past ticketcategorized as “high profile.” For example, the ticket assessment enginemay search a database of past tickets to determine whether the work siteis within a given radius (e.g. 100 yards) of a past ticket with a “highprofile” designation. If so, the ticket assessment engine may assign thecomplexity category “high profile potential” to the current ticket andrecord a reason code “historical high profile” at act 1212.

At act 1214, the ticket assessment engine may determine whether thelocate request ticket is subject to special billing rules. For example,the ticket assessment engine may determine whether the ticket has alinear scope of 0.5 miles or greater (e.g., as determined during thescope assessment process 1100), or whether the work site is at a remotelocation that requires extended travel. Additionally, the ticketassessment engine may search one or more text fields (e.g., locateinstructions, remarks and/or excavation type description) for keywordsthat might be relevant for billing. Then the ticket assessment enginemay consult one or more billing tables to determine whether any specialbilling rules apply to the current ticket. For example, at act 1216, theticket assessment engine may set a hourly status indicator to “true,”indicating that the ticket should be billed per unit of work performed,rather than at a flat rate.

It should be appreciated that the billing tables used by the ticketassessment engine may contain information that is specific to aparticular geographic area. For example, different facility ownersserving different geographical areas may be billed at different ratesusing different methods. Therefore, multiple billing tables may beprepared and selected for use based on the geographic areas in which thelocate service provider is operating.

Proceeding to act 1218, the ticket assessment engine may determine aservice type (e.g., “emergency,” “short notice,” “re-mark,” “re-stake,”or “re-note”) by performing a keyword search. The search may taken intoaccount common abbreviations such as “shrt” for “short.” If a relevantkeyword is found, the ticket assessment engine may record thecorresponding service type at act 1220. This information may be used,for example, during the scheduling and dispatch process to determine adue date or deadline for the ticket. It may also be used in determiningan appropriate fee to be billed to a customer.

As discussed in connection with FIG. 2, some of the above-describedfunctionalities relating to complexity assessment may be expressed via aset of business rules (e.g., one or more of business rules 240 shown inFIG. 2). An exemplary set of complexity assessment business rules issummarized in Table 2 below (BR-001 through BR-005) and described ingreater detail in Tables 3-7.

VI. Time Assessment

As discussed above, various time-related aspects of a locate requestticket may be assessed, such as a due date of the ticket, an estimatedduration of the requested locate operation and/or an expiration date oflocate marks.

In some embodiments, the time at which a locate request ticket isgenerated (e.g., when an excavator notifies a one-call center regardingplanned excavation activities) may be used to estimate one or moredeadlines. For example, depending on a service type associated with theticket (e.g., emergency, short notice, re-mark, etc.), a locate serviceprovider may have more or less time to respond to the ticket. As a morespecific examples, the locate service provider may be required (e.g., bygovernment regulations and/or locate contract provisions) to respond toan emergency ticket within a short window of time (e.g., two to fourhours after the ticket is generated), whereas normal tickets may becompleted within a longer window of time (e.g., 48 or 72 hours after theticket is generated).

The time of ticket generation may also be used to determine when thelocate marks placed by a technician at the work site will expire. Forinstance, in some jurisdictions, an excavator may be required by law orregulation to request a “re-mark” operation if the planned excavationactivities are not completed within a certain period of time (e.g., onthe order of days, such as seven or 14 days) after the original ticketis generated. In response to such a request, a new (but related) workorder may be created to dispatch a locate technician to the work site torepeat the locate operation and/or refresh the locate marks previouslyplaced (e.g., by spraying more paint on the ground at previously markedlocations). If the planned excavation activities are not completedwithin a longer period of time (e.g., on the order of weeks, such asthree or four weeks), the ticket itself may be said to have expired, andthe excavator may be required by law or regulation to initiate a newlocate request ticket.

In some further embodiments, the duration of a locate request ticket(i.e., the amount of time worked by a locate technician to complete therequested locate operation) may be estimated using statisticalinformation collected from previously complete locate request tickets.For example, a ticket assessment engine may access a historical averageand/or standard deviation for tickets of a certain type (e.g., ticketshaving a certain combination of features). This information may then beused to establish an adjustment and/or scaling factor to be applied tofuture tickets of the same type (e.g., having the same combination offeatures).

FIG. 13 shows an illustrative process 1300 that may be performed by aticket assessment engine to estimate the duration of a locate requestticket, in accordance with some embodiments.

At act 1302, the ticket assessment engine may establish an initialduration estimate, for example, based on the total number of facilitiesto be located (e.g., as determined or verified during the scopeassessment process 1100). More specifically, if the ticket is anN-locate ticket (i.e., there are N different types of facilities to belocated), the ticket assessment engine may obtain the historical averageduration for all previously complete N-locate tickets. Alternatively,the ticket assessment engine may obtain the standard deviation inaddition to the average, and determine a duration estimate such that,with high probability, at least a desired percentage (e.g., 95 percents)of all N-locate tickets will have a duration not exceeding the durationestimate. Such an estimate may be computed using any known techniques,such as Chebychev's inequality.

In addition to the number of facilities types to be located, otherticket characteristics may also be used to determine a subset ofpreviously completed tickets based on which a historical averageduration is computed. For example, a historical average duration may becomputed for all previously completed tickets located within a certaingeographical area (e.g., as specified by a geofence). As anotherexample, a historical average duration may be computed for allpreviously completed tickets having one or more common types offacilities (e.g., gas, cable, water, electric, etc.). As yet anotherexample, a historical average duration may be computed for allpreviously completed tickets having a suitable combination of ticketcharacteristics, such as all tickets completed within the past threemonths in a specified city or neighborhood.

At act 1304, the ticket assessment engine may, based on a number ofdifferent factors, determine on or more adjustments to be applied to theinitial duration estimate established at act 1302. For example, anadjustment may be assigned to each facility type based on observedaverages. More specifically, if an N-locate ticket having a firstfacility type (e.g., gas) is on average 4 minutes longer than anN-locate ticket not having the first facility type, then an adjustmentof 4 minutes may be assigned to the facility type “Gas.” On the otherhand, if an N-locate ticket having a second facility type (e.g., sewer)is on average 3 minutes shorter than an N-locate ticket not having thesecond facility type, then an adjustment of −3 minutes may be assignedto the facility type “Sewer.”

As another example, an adjustment may be determined based on complexityregion type (e.g., as determined at during act 1206 shown in FIG. 12).More specifically, it may have been observed that an average tickethaving a complexity region type “Gated” (e.g., the work site is within agated community requiring some form of access approval, such as anaccess code) is 15 minutes longer than an overall average. Then anadjustment of 15 minutes may be assigned to all tickets having acomplexity region type “Gated.” Alternatively, an appropriate adjustmentmay be chosen to guarantee that, with high probability, all tickets withcomplexity region type “Gated” will have a duration not exceeding theaverage duration plus the adjustment. Such an adjustment may be chosenusing any known techniques using standard deviation information.

Similarly, adjustments may be determined for other complexity regiontypes, such as military base (e.g., 35 minutes, due to strictverification procedures for access permits) and/or regions with aerialpower lines (e.g., −10 minutes, because aerial power lines may belocated without special equipment).

At act 1306, various scaling factors may be established for the durationestimate. For example, if a ticket is determined to be high profile witha certain reason code (e.g., as in act 1202 shown in FIG. 12), thereason code may be used to index an appropriate scaling factor. In someembodiments, the scaling factor may be 1.15 for a high profile ticketwith no reason code given, 1.38 for the reason code “Fiber Optic,” and1.23 for reason code “HCPhone” (or high capacity phone line).

A similar, but not necessarily identical, set of scaling factors may bechosen for tickets with high profile potential under reason codehistorical high profile (e.g., as determined in act 1210 shown in FIG.12). For example, the scaling factors for no reason code, reason code“Fiber Optic” and reason code “HCPhone” may be, respectively, 1.08, 1.3and 1.18.

Other complexity designations may also be used to establish scalingfactors. For example, if a ticket's hourly status indicator is set to“true” (e.g., as in act 1214 shown in FIG. 12), the correspondingduration estimate may be scaled based on an estimated size of the digarea (e.g., in length or in area). More specifically, the scaling factormay be obtained by dividing the length of the dig area by a base value(e.g., 0.5 miles), or by dividing the area of the dig area by a basevalue (e.g. 10000 square feet). Similarly, the service type of a ticket(e.g., as determined in act 1218 shown in FIG. 12) may be used to lookup a corresponding scaling factor, such as 1.23 for emergency and 1.82for short notice. On the other hand, a scaling factor of less than 1(e.g., 0.9, 0.8, or 0.6) may be used for a re-mark or re-note operation,assuming the same technician who performed the previous operation isdispatched to perform the re-mark or re-note, in which case thetechnician may be more efficient during the subsequent visit because heis already familiar with the work site.

It should be appreciated that all of the scaling factors may bedetermined based on average and/or standard deviation information usingtechniques similar to those described above for establishingadjustments. Other techniques may also be possible, such as manualoptimizations.

Proceeding to act 1308, any adjustments determined at act 1304 andscaling factors determined at act 1306 may be applied in a suitablemanner to the initial duration estimate determined at act 1302. Forexample, all adjustments may be applied (e.g., added to the durationestimate), and then all scaling factors may be applied (e.g., multipliedwith the duration estimate). Other methods may also be possible, such asbreaking down the duration estimate into different components (e.g., onefor each facility type) and applying appropriate adjustments and/orscaling factors to the individual components, in addition to, or insteadof applying adjustments and/or scaling factors to the overall durationestimate.

Although time assessment is performed on the basis of a locate requestticket in the above described example, it should be appreciated that thepresent disclosure is not so limited. Rather, time assessment may beperformed with respect to any suitable unit of work, which may be largeror smaller than a locate operation corresponding to a locate requestticket. For instance, in various embodiments, time assessment may beperformed with respect to a collection of related locate operations, orwith respect to one or more tasks within a single locate operation.Examples of tasks include, but are not limited to, traveling to a worksite, reviewing a ticket in preparation for the corresponding locateoperation, reviewing a relevant map, equipment preparation, locating oneor more facilities, marking one or more facilities, preparingdocumentation (e.g., electronically or on paper) upon completion of aticket, and/or preparing for departure from work site. Whereappropriate, each of these tasks may be further broken down intosubtasks, for example, based on facility type.

As with complexity assessment, some or all of the above-describedfunctionalities relating to time assessment may be expressed via a setof business rules (e.g., one or more of business rules 240 shown in FIG.2). An exemplary set of time assessment business rules is summarized inTable 2 below (BR-006 through BR-012) and described in greater detail inTables 8-14.

VII. Risk Assessment

In various embodiments, risk assessment may include estimating theextent of potential damages (e.g., economic losses, property and/orenvironmental damages, personal injuries, etc.) in the event of anaccident during subsequent excavation. Additionally, or alternatively,risk assessment may include estimating a likelihood that an accidentwould occur given a set of circumstances (e.g., as described in a locaterequest ticket and/or inferred therefrom).

Risk assessment may be of interest to different entities associated withlocate and/or marking operations. For instance, a locate serviceprovider may wish to assess a level of potential liability for damagesin an accident where the locate service provider is at fault (e.g.,failing to complete a locate operation by a required deadline orinadequately performing a location operation). On the other hand, afacilities owner may wish to assess the extent of potential damage(e.g., the number of customers who may experience service interruptionand/or costs for repairing damaged facilities). If the scope ofpotential damages is sufficiently large, the facilities owner may decideto dispatch an in-house locate technician to perform a locate operation,instead of contracting the operation to a locate service provider. Asanother example, the facilities owner may determine that more stringentsafety procedures may be appropriate where personal injuries are likely(e.g., where a work site is located in a populous area, such as near aschool or a shopping mall), and therefore may also decide to dispatchits own team of locate technicians for a better quality guarantee.

In some embodiments, the risk associated with a locate request ticketmay be represented as a numerical score (e.g., a number between 1 and100) or a broad category (e.g., high, medium or low). As discussed ingreater detail below, the score or category may be determined based onhistorical data, such as the frequency and extent of damage among acertain class of previously completed tickets. This risk measure may beused to flag some of the incoming tickets for special considerationand/or handling. For example, it may be required that a high risk ticketbe handled only by a technician with a high level of skill.Alternatively, or additionally, a high risk ticket may requiresupervisory review after completion, to check for any errors that mayhave been made by the technician performing the requested locateoperations. In this manner, risk assessment may reduce the likelihood ofaccidents, and may thereby improve the profitability of the locateservice provider's operations.

FIG. 14 shows an illustrative process 1400 that may be performed by aticket assessment engine to compute a risk measurement (e.g., anumerical score or category) associated with a locate request ticket, inaccordance with some embodiments.

At act 1402, a risk score may be established for each facility type tobe located. For example, gas, electric and water may be assigned a riskscore of 2.5, 0.7 and 0.2 respectively. These scores may be determinedbased on a number of different factors, such as the frequency of damagesrelated to a facility type (e.g., the percentage of gas locates thatresulted in damage reports) and the extent of damages related to afacility type (e.g., the average monetary value of claims resulting fromdamages to gas pipes). Finer distinctions may also be made, such asassigning different risk scores based on attributes of facilities of thesame type. For example, damages to water mains may result in very highclaim amounts (e.g., streets may collapse due to a ruptured water main),while damages to water lines leading a customer's premise may be minorand easy to repair. As another example, the diameters of gas pipes maybe taken into account, where thicker pipes may be associated with lowergas pressure and may be more at risk for explosions.

At act 1404, the various risk scores determined at act 1402 may besummed to obtain an overall risk score for the ticket. Then, at act1406, one or more appropriate scaling factors may be determined foradjusting the overall risk score. For example, the ticket assessmentengine may access a database of past damage reports to determine whetherthe work site and/or dig area for the current ticket is within a givenradius (e.g., 500 yards) of one or more past damage reports and, if so,computes the total amount of claims from all of the damage reportswithin this radius. This total amount may in turn be used to lookup anappropriate scaling factor for the risk score, for example, as shown inTable 16 below.

In addition to damage reports, scaling factors may, in some embodiments,be determined based on proximity to one or more mis-locates. Amis-locate is said to have occurred when an error in connection with alocate and/or marking operation is discovered (e.g., during subsequentexcavation), although the error may not have manifested itself as anaccident. In some further embodiments, proximity to one or more pasttrouble tickets may also be used in determining a scaling factor.Trouble tickets may include any previously completed tickets whoserecords indicate one or more operational irregularities. For example, apast ticket may be designated as a trouble ticket if the techniciandispatched to the work site had difficulty locating a certain type offacilities and had to call his supervisor for special instructions.

As another example, the ticket assessment engine may determine whetherthe excavator who submitted the excavation notice corresponding to thecurrent ticket has a significant history of damages. This history can bemeasured in a number of different ways. For example, an average damageamount (e.g., in dollar value) per excavation (or locate operation) maybe computed for at least some of the excavators for whom historicalinformation is available. The average may be computed over a certaintime frame (e.g., the past six months, or one, two, three, five or tenyear). The average across different excavators may also be computed.

Then the ticket assessment engine may compare a particular excavator'saverage damage amount against the average across all excavators, forexample, by expressing the former as a percentage of the latter. Thispercentage may be used to look up a corresponding scaling factor for theoverall risk score of the ticket (e.g., as shown in Table 17 below).

Alternatively, or additionally, a damage count (e.g., the number ofdamage reports irrespective of the dollar amount for each report) may beobtained for each excavator and compared against an average damage countacross different excavators, for example, over a certain time frame(e.g., the past six months, or one, two, three, five or ten year).Again, a particular excavator's damage count may be expressed as apercentage of the average damage count, and the percentage may be usedto look up an appropriate scaling factor (e.g., as shown in Table 17below).

Complexity designations such as high profile may also be used todetermine one or more appropriate scaling factors for the overall riskscore. For example, if a ticket is determined to be high profile with acertain reason code (e.g., as in act 1202 shown in FIG. 12), the reasoncode may be used to index an appropriate scaling factor. In someembodiments, the scaling factor may be 1.8 for a high profile ticketwith no reason code given, 4.0 for the reason code “Fiber Optic,” and2.5 for reason code “HCPhone” (e.g., as shown in Table 18 below).

As another example, if a ticket's hourly status indicator is set to“true” (e.g., as in act 1214 shown in FIG. 12), the corresponding riskestimate may be scaled based on an estimated size of the dig area (e.g.,in length or in area). In the embodiment described in Table 20 below,the scaling factor may be obtained by dividing the length of the digarea by a base value (e.g., 0.5 miles), or by dividing the area of thedig area by a base value (e.g. 10000 square feet). Similarly, theservice type of a ticket (e.g., as determined in act 1218 shown in FIG.12) may be used to look up a corresponding scaling factor, such as 2.85for emergency, 3.46 for 2-hour short notice, and 3.11 for 3-hour shortnotice (e.g., as shown in Table 19 below).

VIII. Value Assessment

As discussed above, value assessment may be performed according todifferent measures of value. For instance, value assessment may beperformed from the perspective of a locate service provider based onbusiness value created by performing a locate operation. In someembodiments, such business value may simply be the revenue collected forperforming the locate operation. Alternatively, or additionally, ameasure of net profit may be used, where various operating costs may besubtracted from the revenue.

In some embodiments, a measure of profit may take into accountinformation from one or more contracts established between a locateservice provider and a facilities owner (or some other entitycontracting with the locate service provider to perform locateoperations). Examples of contractual information include, but are notlimited to, contractual provisions specifying bonuses and/or penaltiesfor certain tickets. For instance, a locate contract may provide that apenalty (e.g., a suitable percentage of the contract price forperforming a locate and/or marking operation) be assessed if the locateservice provider fails to meet a deadline specified in a locate requestticket. Accordingly, the value associated with the ticket may be afunction of time that has a sharp decline at the specified deadline. Asan other example, the locate contract may further provide that a penaltybe assessed for each billing period during which the locate serviceprovider fails to timely respond to an excessive number of tickets. Anysuitable mechanism may be used to define when a penalty should beassessed, such as a percentage threshold (e.g., more than 5%, 10% or 15%of tickets being completed late). The penalty may also be assessed inany suitable manner, for example, in the form of a fixed percentage(e.g., 1%, 2%, 3% or 5%) applied to all tickets, or with step increases(e.g., penalizing more heavily when a higher percentage of tickets arecompleted late). Accordingly, the value associated with the currentticket may depend not only on the time at which the requested operationis performed, but also on the number of tickets that have been completedlate in the same billing period. For example, if the percentage oftickets that have been completed late in the same billing period isapproaching 5%, the decline in value at the ticket deadline may includenot only the penalty for missing the deadline of the individual ticket,but also the penalty for missing the deadlines of 5% of the tickets inthat billing period.

In some further embodiments, value assessment may be performed from theperspective of an entity other than the locate service provider, such asa facilities owner, an excavator, a one-call center, a community (e.g.,city, town, village, and/or other form of municipality) and/or aninsurance company. One or more of these entities may perform valueassessments based on their interests and concerns. For instance, afacilities owner may measure value in terms of value at risk (e.g.,potential costs for repairing damages to facilities and/or restoringservices in the event of an accident). Likewise, a community may use avalue-at-risk measure, but the potential damages may be different (e.g.,repairing property damage and/or environmental cleanup).

Additionally, value need not be restricted to monetary value. It may beany custom defined value, or even a time-varying function. For example,as discussed above, the value estimate may be provided to a schedulingand dispatch application (e.g., the scheduling and dispatch application260 shown in FIG. 2), which may use the value estimate to prioritizeactivities. Thus, the value estimate may be used as a means to encouragea desired scheduling behavior. For example, if a ticket falls within acertain geographic area known to have heavy traffic during certain timesof day, the value estimate may be defined as a function that has lowervalue during the periods of heavy traffic and higher values elsewhere.This may encourage the scheduling and dispatch application to avoiddispatching the ticket during the periods of heavy traffic.

Similarly, the ticket assessment engine may access an up-to-date sourceof weather information and define the value estimate as a time-varyingfunction according to the weather forecast for the work site. Forinstance, the value estimate function may be defined in such a way thatthe scheduling and dispatch application is encouraged to avoiddispatching a technician to the work site in weather conditions that mayhinder the locating and marking of underground facilities (e.g., rain orsnow).

FIG. 15 shows an illustrative process 1500 that may be performed by aticket assessment engine to compute an estimated value (e.g., expectedrevenue) for a locate request ticket.

At act 1502, the ticket assessment engine may determine if the ticket isa duplicate ticket, such as a re-mark, re-stake or re-note ticket. Undersome service contracts, such tickets may not be billed if the re-mark,re-stake or re-note is necessitated due to some action, or lack ofaction, by the locate service provider. Additionally, some servicecontracts may specify that two tickets transmitted on the same day areduplicate tickets if the corresponding work sites are sufficiently closeto each other, and that only one of the duplicate tickets may be billed.

If the ticket is determined to be a duplicate ticket, then the ticketassessment engine sets the revenue to zero at act 1504. Otherwise, theticket assessment engine may determined the applicable billing method atact 1506, for example, whether the ticket should be billed at a flatrate, per unit of work performed, or per hour worked.

If the ticket is to be billed at a flat rate, the ticket assessmentengine may proceed to act 1508 and consult a billing rate table toselect an appropriate flat rate, for example, based on the type offacility located and/or the identity of the facility owner. Otherwise,the ticket assessment engine may proceed to act 1510 and determine anappropriate billing rate, which may be either per unit of work performed(e.g., unit length of facility marked, unit area of dig area located, orsome other custom-defined unit of work) or per hour worked. Then theticket assessment engine may proceed to act 1512 to obtain an estimatedscope of the ticket (e.g., as determined during the process 1100 shownin FIG. 11) or an estimated duration of the ticket (e.g., as determinedduring the process 1300 shown in FIG. 13). Based on the rate informationand the scope or time information, the ticket assessment engine maycompute an estimated revenue amount for the ticket.

It should be appreciated that the process 1500 may alternatively beperformed on a per facility type basis. That is, a revenue estimate maybe determined for each facility type to be located using a processsimilar to the process 1500. Then the separate revenue estimates may besummed to obtain a total estimate for the ticket.

Furthermore, value assessment may take into account one or more otherassessment outcomes in addition to, or instead of, estimated scope orduration. For example, as illustrated in FIG. 17 and discussed ingreater detail below, value assessment may, directly or indirectly, beinformed by assessment outcomes relating to location, complexity, risk,and resource.

As with other types of assessment, some of the above-describedfunctionalities relating to value assessment may be expressed via a setof business rules (e.g., one or more of business rules 240 shown in FIG.2). An exemplary set of value assessment business rules is summarized inTable 2 below (BR-019 through BR-022) and described in greater detail inTables 20-23.

IX. Resource Assessment

As discussed above, resource assessment may include identifying one ormore resources (e.g., equipment and/or personnel) needed and/orrecommended to adequately perform a requested locate operation. Forinstance, ticket information, auxiliary information and/or outcomes fromother types of assessment (e.g., scope and/or complexity) may beanalyzed to determine whether any resource requirements and/orrecommendations exist for the requested locate operation.

FIG. 16A shows an illustrative process 1600A that may be performed by aticket assessment engine to identify one or more pieces of equipmentthat may be required and/or recommended for a locate operation but maynot be available to a locate technician under ordinary circumstances(e.g., not included in a standard set of equipment carried by a locatetechnician).

At act 1602A, one or more maps may be retrieved based on a work sitelocation that is obtained either from the ticket information or as anoutcome of location assessment. The retrieved maps may be analyzed toidentify any equipment that may be useful in performing the requestedlocate operation. For example, a facilities map may be retrieved andanalyzed to determine whether one or more manholes are located at ornear the work site and/or whether a locate technician would need toconnect a locate transmitter to a connection point in a manhole.

If it is determined that the locate technician likely needs to removeone or more manhole covers during the course of the locate operation, a“sissy hook” (or “sissy bar”), or a similar device for facilitatingmanhole recover removal, may be recommended. In some situations, suchsafety devices may be required by a worker's safety organization such asthe Occupational Safety and Health Administration (OSHA). An insurancecompany may also require the use of certain safety devices as aprecondition to payment of damage or injury claims. Furthermore, if itis determined that a locate technician would need to connect a locatetransmitter to a connection point in the manhole, a hot stick may berecommended, which could be used to secure the connection between thelocate transmitter and the connection point without the locatetechnician physically entering the manhole.

As a further example, it may be determined, at act 1602A, based on worksite location and one or more facilities maps, that the technicianlikely needs to open a telephone box on a pedestal, in which case thetechnician may be recommended to bring a pedestal wrench, or a similartool, for facilitating the opening of a telephone box.

In addition to facilities maps, one or more street maps may also beretrieved and analyzed at act 1602A. For instance, it may be determinedbased on the work site location and one or more street maps that thework site is in an urban setting, in which case a less persistentmarking material (e.g., washable paint) may be recommended so as toreduce the impact of the locate marks on the aesthetic appearance of thework site. On the other hand, if it is determined that the work site isin a high traffic area (e.g., on or near a highway), a more persistentmarking material (e.g., oil-based paint) may be recommended so as toreduce the likelihood of the locate marks wearing off prior toexcavation.

Continuing with FIG. 16A, the ticket assessment engine may, at act1604A, retrieve and analyze historical information (e.g., one or morerecords of previously completed locate and/or marking operations). Forexample, it may be determined based on work site location and historicalinformation that the work site likely has bad tracer wires, in whichcase a more advanced locate transmitter and/or receiver may be needed toobtain sufficient signal strength (e.g., locate transmitter and/orreceiver with different frequency ranges). Alternatively, oradditionally, a different type of locate device may be recommended, suchas a sonar or ground penetrating radar device (e.g., the “Inspector 07”locator marketed by Subsurface Instruments, Inc.), which may be used tolocate underground facilities without being hooked up to tracer wires.

As another example, it may be determined, at act 1604A, based on worksite location and historical information, that the work site is likelyto have such dry ground as to prevent adequate ground connection, inwhich case the technician may be recommended to bring a bottle of waterto wet the ground before attempting to make a ground connection.

Continuing to act 1606A, the ticket assessment engine may examine a digarea description (e.g., as provided in a free text portion of the locaterequest ticket) to identify any special circumstances that may requireaddition equipment. For instance, the dig area description may indicatethat the work site is within a construction zone, in which case thelocate technician may be required to wear a hard hat while on site.

Although specific examples of equipment-related analyses are illustratedin FIG. 16A and described above, it should be appreciated that theinventive concepts disclosed herein are not limited to any specificimplementations. For instance, the need to remove manhole covers may beinferred based on information other than facilities maps. As oneexample, if the work site is located in an urban or densely populatedarea, it is likely that the locate technician would encounter at leastone manhole. As another example, an image of the work site (e.g., a VWLimage based on an aerial image of the work site) may be consulted todetermine whether one or more manholes are present. As yet anotherexample, the need to remove manhole covers may be explicitly indicatedin a free text portion of the locate request ticket (e.g., in a locateinstructions section). Furthermore, one or more contracts establishedbetween a locate service provider and a facilities owner (or some otherentity contracting with the locate service provider to perform locateoperations) may specify particular tools/equipment requirements for sometypes of locate operations, in which case the ticket assessment enginewould consult auxiliary information such as contract information and anyparticular contractual obligations therein relating to tool and/orequipment requirements.

Additionally, the ticket assessment engine may recommend or requirecertain equipment without analyzing any auxiliary information. Forinstance, a locate technician may be required or recommended to reviewone or more facilities maps upon arrival at a work site to familiarizehimself with the layout of underground facilities at the work site(e.g., general directions of various facilities lines, locations ofconnection points, etc.) and to plan his work accordingly. Therefore,the ticket assessment engine may identify one or more relevantfacilities maps (e.g., based on the work site location) as beingrecommended or required for the locate operation.

In some further embodiments, resource assessment may identify apersonnel skill level or certification required and/or recommended toperform a locate operation. For example, in some jurisdictions, only atechnician with gas certification may be dispatched to perform a locateoperation involving gas pipes. In another example, one or moreassessment outcomes (e.g., scope, location, complexity, time and/orrisk) may be used to determine a minimum skill level requirement for thelocate operation. As a more specific example, a ticket may be assigned ahigh complexity level due to complex layout of underground facilities ator near the work site, in which case it may be desirable to dispatch atechnician with knowledge and/or familiarity of the geographical areaencompassing the work site.

In some embodiments, personnel skill level may include both long termmeasurements (e.g., years of experience and/or cumulative training) andshort term measurements (e.g., recent performance evaluations).Furthermore, statistics may be collected regarding each technician'sperformance patterns. For instance, a technician may consistent performat a higher level during certain hours of day (e.g., in the morning orin the afternoon), and may be assigned different skill levels dependingon the time of day of dispatch.

FIG. 16B shows an illustrative process 1600B that may be performed by aticket assessment engine to identify one or more requirements and/orrecommendations for selecting a suitable technician to perform arequested locate operation. As discussed above, skill requirementsand/or recommendations may refer broadly to any suitable attributes of atechnician, including experience level, past performance level (e.g.,both long term and short term), certifications, and/or securityclearance.

At act 1602B, the ticket assessment engine may determine skillrequirements based on the types of facilities to be located. Forexample, a contract with a facility owner (e.g., gas) may require thatonly technicians with the appropriate certification (e.g., gascertification) be dispatched to locate facilities owned by that facilityowner. This may be done by consulting a lookup table that maps facilitytypes to skill requirements (e.g., the lookup table 850 shown in FIG.8).

At act 1604B, the ticket assessment engine may determine whether theticket is associated with any complexity types (e.g., as determinedduring the process 1200 shown in FIG. 12). If so, the ticket assessmentengine may look up any skill requirements associated with the identifiedcomplexity types. For example, a complexity reason code “Military Base”may indicate that only technicians with certain levels of securityclearance may gain access to the work site. As another example, for ahigh profile ticket (e.g., by reason of high profile facilities typesand/or proximity to historical damages), a high level of experienceand/or good performance may be recommended.

At act 1606B, the ticket assessment engine may obtain a risk score forthe ticket (e.g., as determined during the process 1400 shown in FIG.14) and look up any applicable skill requirements. For example, atechnician with a high level of experience and/or good performance maybe recommended and/or required for a high risk ticket.

Although detailed examples of resource assessment are described above inconnection with FIGS. 16A-B, it should be appreciated that the inventiveconcepts disclosed herein are not limited to any specificimplementations. For example, to the extent that the resource-relatedanalyses are independent from each other, they may be performed in anysuitable order (e.g., not necessarily in the orders presented in FIGS.16A-B).

As with other types of assessment, some of the above-describedfunctionalities relating to skill requirements assessment may beexpressed via a set of business rules (e.g., one or more of businessrules 240 shown in FIG. 2). An exemplary skill requirements assessmentbusiness rule is described in Table 26 below.

X. Detailed Example of Ticket Assessment

FIG. 17 shows an illustrative example of a ticket assessment processexecuted by a multi-stage ticket assessment engine (e.g., the ticketassessment engine 230 shown in FIGS. 2 and 2A), having a network ofassessment modules or subprocesses. The assessment modules may bearranged in multiple stages (e.g., six stages), where an assessmentmodule at each stage may receive as input one or more intermediateoutcomes of assessment from one or more previous stages. For instance,in the embodiment shown in FIG. 17, a first stage may include a scopeassessment module 1710A and a location assessment module 1710B, a secondstage may include a complexity assessment module 1820A, a third stagemay include a duration assessment module 1730A and a risk assessmentmodule 1730B, a fourth stage may include a resource assessment module1740A, a fifth stage may include an adjusted duration assessment module1750A, and a sixth stage may include a value assessment module 1760A.

In the example shown in FIG. 17, the ticket assessment process mayreceive as initial input a locate request ticket (e.g., the ticket 300shown in FIG. 3) as part of ticket information 225. Various informationelements may be extracted from the input ticket (e.g., using a ticketparsing process such as the one shown in FIG. 5 and described above) andprovided to various assessment modules. For example, scope-relatedinformation such as polygon and/or dig area indicator coordinates and/ormember codes identifying one or more notified facilities owners may beextracted and provided to the scope assessment module 1710A.Additionally, one or more relevant facilities maps 255A may be accessed(e.g., from the auxiliary information storage 250 shown in FIG. 2) andprovided to the scope assessment module 1710A. Based on these pieces ofinformation, the scope assessment module 1710A may output the number offacilities to be located pursuant to the input ticket, as well as anindication of whether the facilities to be located include one or morehigh profile gas facilities.

As a more specific example, with reference to FIG. 3, the member codesshown at 314 (e.g., “FP=W&SA,” “KD=TWNSND WRTR,” “KC=PECO PLMG,” and“XZ=COMCAST CABLE B”) may indicate a total of four facilities types tobe located (e.g., sewer, water, gas, and cable). The scope assessmentmodule 1710A may further determine that a high profile gas facilitiestype is present (e.g., as indicated by the member code “KC=PECO PLMG”).

As another example, location-related information such as work siteaddress and/or GPS coordinates may be extracted from the input ticketand provided to the location assessment module 1710B. Additionally, oneor more relevant street maps 255B may be accessed (e.g., from theauxiliary information storage 250 shown in FIG. 2) and provided to thelocation assessment module 1710B, which may analyze the street maps 255Bto determine whether the work site is likely to be in a rural area(e.g., as distinguished from an urban or suburban area). The outcome ofthat determination may be output by the location assessment module1710B.

As a more specific example, with reference to FIG. 3, the work siteaddress shown at 304A (e.g., “100 St. Francis Ln” in “Bensalem Twp”) maybe extracted from the ticket 300 and provided to the locate assessmentmodule 1710B, which may determine that the work site is not located in arural area.

Proceeding to the second stage of assessment, one or more outputs of thefirst stage, such as the indication of whether one or more high profilegas facilities are to be located and the indication of whether the worksite is located in a rural area, may be provided to the complexityassessment module 1720A, which may analyze those intermediate assessmentoutcomes and assign a complexity category to the input ticket. Forexample, the complexity assessment module 1720A may implement thefollowing decision table.

TABLE 1A Location Complexity Rural Not Rural Scope High Profile GasMedium High Not High Profile Gas Low Medium

As a more specific example, the scope assessment module 1710A maydetermine that the input ticket does request that one or more highprofile gas facilities be located, and the location assessment module1710B may determine that the work site is not located in a rural area.As a result, the complexity assessment module 1720A may assign acomplexity level of “High” to the input ticket.

Proceeding to the third stage of assessment, one or more outputs of thefirst and second stages, such as the number of facilities to be locatedand the complexity category, may be provided to the duration assessmentmodule 1730A, which may analyze those intermediate assessment outcomesand output an estimated duration for completing the input ticket. Forexample, the duration assessment module 1730A may assume that a certainamount of time (e.g., 10 minutes) may be needed to locate each type offacilities, and that the total duration may be scaled according to thecomplexity category (e.g., scaling factors of 1, 1.2 and 1.5 may beapplied, respectively, to the complexity categories low, medium andhigh).

As a more specific example, the scope assessment module 1710A maydetermine that the input ticket requests a total of four facilities tobe located. Because the complexity assessment module 1720A has assigneda complexity level of “High” to the input ticket. the durationassessment module 1730A may compute an estimated duration for the inputticket as follows:

4 facilities types*10 minutes per facilities type*scaling factor 1.5=60minutes.

Additionally, the number of facilities to be located and the complexitycategory may be provided to the risk assessment module 1730B, which mayanalyze those intermediate assessment outcomes and assign a riskcategory to the input ticket. For example, the risk assessment module1730B may implement the following decision table.

TABLE 1B Number of Facilities Risk 1 2 3 4 5 Complexity High MediumMedium High High High Medium Low Low Medium Medium High Low Low Low LowMedium Medium

In this example, because the scope assessment module 1710A hasdetermined that the input ticket requests a total of four facilities tobe located, and the complexity assessment module 1720A has assigned acomplexity level of “High” to the input ticket, the risk assessmentmodule 1730B may assign a risk level of “High” to the input ticket. Thisoutcome may be output by the overall assessment process as a finaloutcome, Risk Assessment Outcome 1772, which may be used by other ticketmanage system components, such as the scheduling and dispatchapplication 260 shown in FIG. 2.

The output of the risk assessment module 1730B may also be anintermediate outcome consumed by an assessment module at a subsequentstage, such as the resource assessment module 1740A at the fourth stage,which may determine an appropriate technician skill level according tothe risk category assigned to the input ticket. For instance, theresource assessment module 1740A may determine that a high risk ticketmay require a technician skill level of “expert,” a medium risk ticketmay require a technician skill level of “experienced” or higher, and alow risk ticket may be dispatched to any technician, including those ata “trainee” level. In this example, because the risk assessment module1730B has assigned a risk level of “High” to the input ticket, theresource assessment module 1740A may determine that an expert technicianmay be required. As for the risk assessment outcome, the resourceassessment outcome may be output as a final outcome, Resource AssessmentOutcome 1774, for use by other ticket manage system components.

Proceeding to the fifth stage of assessment, one or more outputs of theprevious stages, such as the estimated duration and the technician skillrequirement, may be provided to the adjusted duration assessment module1750A, which may adjust the estimated duration based on technician skilllevel. For example, the adjusted duration assessment module 1750A mayapply scaling factors of 1, 1.1 and 1.3, respectively, to tickets withtechnician skill levels of expert, experienced and trainee. As anotherexample, the adjusted duration assessment module 1750A may apply one ormore scaling factors to the estimated duration based on a resourceassessment outcome relating to required or recommended equipment. Forinstance, the estimated duration may be adjusted upward if a piece ofadditional or more advanced equipment (e.g., an “Inspector 07” locator)is required or recommended.

In the example illustrated in FIG. 17, because the duration assessmentmodule 1730A has output 60 minutes as the estimated duration, and theresource assessment module 1740A has determined that an experttechnician may be required, the adjusted duration assessment module1750A may compute an adjusted duration for the input ticket as follows:

60 minutes*scaling factor 1=60 minutes.

As for risk and resource, the adjusted duration may be output as a finaloutcome, Time Assessment Outcome 1776, for use by other ticket managesystem components.

Proceeding to the sixth stage of assessment, one or more outputs of theprevious stages, such as the number of facilities to be located and theadjusted duration, may be provided to the value assessment module 1760A,which may analyze those pieces of information and estimate the amount ofprofit to be gained by completing the input ticket. For example, thevalue assessment module 1760A may access contractual information fromone or more databases to determine an amount of revenue that the locateservice provider can expect to collect for completing the input ticket.The value assessment module 1760A may also access employee and/orcompany information from one or more databases to determine an estimatedcost for completing the ticket, which may include techniciancompensation, materials costs and/or overhead costs. As a more specificexample, the value assessment module 1760A may determine that theexpected revenue rate is $10 per type of facilities located and theexpected cost is $0.5 per minute worked.

In this example, because the scope assessment module 1710A hasdetermined that a total of four facilities types are to be located andthe adjusted duration assessment module 1730A has output 60 minutes asthe adjusted duration, the value assessment module 1760A may compute theestimated profit as follows:

4 facilities types*$10 per facilities type−60 minutes*$0.5 perminute=$10.

As for risk, resource and adjusted duration, the estimated profit may beoutput as a final outcome, Value Assessment Outcome 1778, for use byother ticket manage system components.

Although various implementation details are shown in FIG. 17 anddescribed above, it should be appreciated that such details are providedmerely for purposes of illustration, and that the present disclosure isnot limited to these specific examples. For example, various assessmentmodules need not be arranged in linearly ordered stages. Rather, thenetwork of assessment modules can have any suitable configuration (e.g.,including one or more loops). Additionally, the businesses rulesimplemented by the assessment modules of FIG. 17 are provided solely forpurposes of illustration, as other business rules may also be suitable(e.g., the business rules shown in Tables 2-26 below).

XI. Example of Work Order

FIG. 18 shows an example of a work order 1800 that may be created froman incoming locate request ticket (e.g., the ticket 300 shown in FIG.3). As shown, the work order 1800 may include a plurality of informationelements extracted from the ticket 300, such as ticket number 1802,address of work site 1804, excavation information 1806, due dateinformation 1808, excavator information 1810, etc. These informationelements may be presented in the work order 1800 in a different formatcompared to the ticket 300. The work order 1800 may also includeadditional information elements, such as a work order number 1812different from the ticket number (e.g., multiple different work ordersmay be created based on the same ticket), an expected duration 1814(e.g., as determined during the process 1300 shown in FIG. 13) and workorder task information 1816 listing the facility types to be locatedwithin this work order.

The work order 1800 may be forwarded by the ticket assessment engine toother software applications for further processing. For example, thescheduling and dispatch application 260 (as shown in FIG. 2) mayschedule the work order to commence at a certain date and time (e.g.,Jan. 4, 2009 at 9:00 AM, as shown in FIG. 18).

XII. Backend and On-Going Assessments

As discussed above, a feedback mechanism (e.g., the backend assessmentmodule 290 shown in FIG. 2) may be provided in accordance with someembodiments to review completed tickets and perform various informationupdates. For example, the various processes carried out by the ticketassessment engine 230 may rely on historical information, such asstatistical information regarding previously completed tickets. Forimproved performance and reliability, it may be desirable to update thehistorical and/or statistical information on an on-going basis, as morecompleted tickets are accumulated over time.

Accordingly, in some embodiments, the backend assessment module 290 maybe programmed to make adjustments to the assessment business rules 240shown in FIG. 2. For example, any historical averages used in theassessment business rules 240 may be updated on a regular basis. As amore specific example, an illustrative business rule BR-007 is shown inTable 9 below, which is based on historical average durations of locateoperations. As shown in Table 9, the duration of a 3-locate ticket forwhich sewer is one of the facility types to be located may be, onaverage, three minutes shorter than that of a 3-locate ticket without asewer locate. Such an adjustment in duration may be adjusted regularly(e.g., daily, weekly, monthly, annually, etc.), or according to anyother suitable schedule, based on data collected from recently completedlocate operations.

It should be appreciated that the analysis of a previously completedlocate operation may be informed by an outcome of the excavationactivities that took place subsequent to the locate operation. In oneillustrative scenario, it may be observed that the duration of thelocate operation was two minutes shorter than average. However, it maybe further observed that an accident occurred during subsequentexcavation and a probable cause of the accident was misplacement oflocate marks. In that case, the duration of the locate operation may beconsidered an anomaly and may not be used to adjust the historicalaverage duration used for assessing future tickets.

In addition to making adjustments to existing business rules, new rulesmay be added as new patterns are observed from newly accumulatedinformation. For example, a pattern may emerge that locate operationswithin 2 miles of central Manhattan, N.Y. are, on average, four minuteslonger than locate operations conducted elsewhere. Accordingly, a newrule may be defined to adjust the estimated duration upward by fourminutes for all locate request tickets within 2 miles of centralManhattan, N.Y. Alternatively, a new complexity type may be created(e.g., “high density urban”) and all locate operations within 2 miles ofcentral Manhattan, N.Y. may be assigned the new complexity type. Newbusiness rules may then be defined to adjust the estimated durationupward for all locate operations having the new complexity type.

Additionally, the facilities maps available from one-call centers and/orfacility owners may not always contain sufficient and accurateinformation. For example, for some historic urban neighborhoods, theonly available facilities maps may have been created many years ago andmay not contain absolute location information such as lat/longcoordinates. Some of the street-level landmarks shown on the maps mayhave been moved or no longer exist. In such a situation, it may bedifficult to determine the exact location of some of the facilitiesshown on the maps.

Thus, in accordance with some embodiments of the present disclosure, theGIS 610 shown in FIG. 6 may be used as part of a system for continuallyimproving the quality of available facilities maps. For example, the GIS610 may be used to digitize existing maps printed on paper or cloth andaugment the digitized maps with geospatial metadata.

In some instances, the geospatial metadata added to facilities maps maybe generated at least partially based on previously completed locaterequest tickets. For example, the backend assessment module 290 shown inFIG. 2 may be adapted to recognize some geographic areas as areas withinsufficient information and may forward to the GIS 610 the results ofcompleted location operations in those areas, which may includetechnician logs and/or geotagged images with technician annotationsindicating marked facilities. Using this information, the GIS 610 may beable to derive accurate location information for the marked facilitiesand augment the facilities maps accordingly with some appropriategeospatial metadata.

As another example, the backend assessment module 290 may be programmedto discover inconsistencies between existing facilities maps and theactual result of a completed locate operation, and to notify the GIS 610of the discovered inconsistencies. Alternatively, the GIS 610 may beadapted to receive from a human user an indication that there is anerror on an existing facilities map. In either situation, the GIS 610may respond by verifying the report of inconsistency and correcting thefacilities map accordingly.

In some further embodiments, the backend assessment module 290 may beprogrammed to perform time-related analyses based on completed tickets.The types of time-related analyses of interest may vary according theentity from whose perspective the analyses are performed. For instance,from the perspective of a locate service provider, it may be desirableto analyze not only total on-site time (e.g., the length of time betweena technician arriving at a work site and the technician departing fromthe work site upon completion of the requested locate operation), butalso a breakdown of the total duration into individual tasks, such asequipment preparation, locating, marking final documentation and/orpersonal breaks. Each task may be further broken down, for example, intosubtasks each pertaining to a particular type of facilities. The locateservice provider may also analyze travel time, for example, betweensuccessive locate operations and/or daily, weekly or monthly totals.These types of fine-grained analyses (e.g., analyzing durations ofsmaller units of work) may help the locate service provider identifypotential quality and/or efficiency issues.

For instance, in some embodiments, the backend assessment module maycompare each technician's record against fleet-wide and/or historicalrecords and may, as a result, identify a technician who consistentlyspends too much (or too little) time when locating a particular type offacilities. This may suggest further training for the technician withrespect to the particular facilities type to ensure that the techniciancorrectly follows the recommended procedures. As another example, thebackend assessment module may identify a technician whose patterns ofpersonal breaks negatively impact his work efficiency, in which casecoaching may be appropriate.

Time-related analyses may also be performed from the perspective of anentity other than a locate service provider, such as a regulatory body,a one-call center and/or an insurance company. For instance, aregulatory body or one-call center may be more interested in timelycompletion of tickets (e.g., reporting percentage of tickets that arecompleted on time and/or identifying tickets that are completed late)and less interested in work duration (e.g., length of time taken tocomplete the requested locate operation or a task within the requestedlocate operation). Statistics on response time (e.g., length of timebetween receiving a ticket from a one-call center and completing therequested locate operation) may also be of interest.

In yet some further embodiments, the backend assessment module 290 maybe programmed to review completed tickets and identify suitablecandidates for human review. For instance, a regulatory body may usedthe backend assessment module to identify high risk and/or high valuetickets to be audited. A quality control application (e.g., the qualitycontrol application 270 shown in FIG. 2) may be employed in conjunctionwith the backend assessment module to further filter the identified highrisk and/or high value tickets. For instance, the quality controlapplication may flag those tickets with potential quality issues (e.g.,technician unable to gain access to dig area, insufficient locatesignals, inclement weather during operation, etc.) Alternatively, thebackend assessment module may itself be programmed to perform some orall of the quality control analysis. In either manner, backendassessment may be employed to reduce the volume of completed ticketsthat require human review, without unacceptable degradation in safety.Examples of manual, semi-automated and automated quality assessmenttechniques that may be implemented as part of backend assessment can befound in one or more of the following references, each of which isincorporated herein by reference:

U.S. patent application Ser. No. 12/493,109, filed on Jun. 26, 2009,entitled “Methods and Apparatus for Quality Assessment of a FieldService Operation;”

U.S. patent application Ser. No. 12/557,732, filed on Aug. 7, 2009,entitled “Methods and Apparatus for Quality Assessment of a FieldService Operation Based on Geographic Information;”

U.S. patent application Ser. No. 12/571,356, filed on Sep. 30, 2009,entitled “Methods and Apparatus for Analyzing Locate and MarkingOperations with Respect to Facilities Maps;”

U.S. patent application Ser. No. 12/572,202, filed on Oct. 1, 2009,entitled “Methods and Apparatus for Analyzing Locate and MarkingOperations with Respect to Historical Information;”

U.S. patent application Ser. No. 12/568,087, filed on Sep. 28, 2009,entitled “Methods and Apparatus for Generating an Electronic Record ofEnvironmental Landmarks Based on Marking Device Actuations;”

U.S. patent application Ser. No. 12/572,260, filed on Oct. 1, 2009,entitled “Methods and Apparatus for Analyzing Locate and MarkingOperations with Respect to Environmental Landmarks;” and

U.S. patent application Ser. No. 12/703,809, filed on Apr. 14, 2010,entitled “Marking Apparatus Equipped with Ticket Processing Software forFacilitating Marking Operations, and Associated Methods.”

TABLE 2 Example rules of assessment business rules 240 Number CategoryImpacts Name Description BR-001 Complexity Time, Keywords - Use keywordsto predict complexity Risk, Complexity potential and/or high Resourceprofile potential BR-002 Complexity Time, Complexity Determine whetherexcavation notice Risk, Region - is within a Complexity Region ResourceComplexity BR-003 Complexity Time, Proximity to Use proximity tohistorical high Risk, Historical High profile tickets to estimate highResource Profile - High profile potential Profile BR-004 ComplexityTime, Project/Hourly Determine if a project/hourly scope Risk, Scope -applies to the excavation notice Resource, Complexity Revenue BR-005Complexity Time, Emergency/Short Determine if an emergency/short Risk,Notice Type - notice type applies to the excavation Resource Complexitynotice BR-006 Time Time Locate Count - Use number of locates to setinitial Time estimate of ticket duration BR-007 Time Time FacilityType - Use facility types to be located to Time adjust estimated ticketduration BR-008 Time Time High Profile - Use high profile certainty toadjust Time estimated ticket duration BR-009 Time Time High Profile Usehigh profile potential to adjust Potential - Time estimated ticketduration BR-010 Time Time Complexity Use complexity regions to adjustRegions - Time estimated ticket duration BR-011 Time Time Service Type -Use the service type (emergency or Time short notice) to adjustestimated ticket duration BR-012 Time Time Project/Hourly Adjustduration for project/hourly Scope - Time scope excavation notice BR-013Risk Risk Facility Types - Use facility types to estimate risk RiskBR-014 Risk Risk Proximity to Use proximity to historical damageHistorical High reports to adjust estimated risk Profile - Risk BR-015Risk Risk Excavator Use excavator damage history to Damage History -adjust estimated risk Risk BR-016 Risk Risk High Profile Use highprofile potential to adjust Potential - Risk estimated risk BR-017 RiskRisk Service Type - Use the service type (emergency or Risk shortnotice) to adjust estimated risk BR-018 Risk Risk Project/Hourly Adjustrisk for project/hourly scope Scope - Risk excavation notice BR-019Value Value Billing Rules Per Apply applicable Per Ticket billingTicket - Value business rates and rules to determine value BR-020 ValueValue Duplicate Ticket Apply duplicate ticket rules to Rules - Valuedetermine if billing value is zero BR-021 Value Value Billing Rates ByApply applicable By Unit billing Unit- Value business rates and rules todetermine value BR-022 Value Value Project/Hourly Adjust value forproject/hourly scope Scope - Value excavation notice BR-023 ResourceResource Determine Determine skill requirements for the Resourceexcavation notice Requirements - Skill

TABLE 3 First example complexity determination of assessment businessrules 240 Business BR-001 (of Table 2) Rule ID Business Keywords -Complexity BR Category: Rule Name CPL Business Rule Use keywords topredict complexity potential and/or high Description profile potentialFields Excavation Notice ID, Work Order Number, Task ID, locate Requiredinstruction text, comment text, excavation type description Rule IFexcavation type description contains FiOS Operation THEN complexity type= High Profile Potential Example Implemen- The keywords will be storedin a decision table as an input column, tation with corresponding valuesfor complexity type and high potential reason description. For example:KEYWORD HIGH PROFILE COMPLEXITY TYPE REASON DESCRIPTION FiOS HighProfile Potential Fiber Optic Gated Gated AFB Military Base AerialAerial Power Lines

TABLE 4 Second example complexity determination of assessment businessrules 240 Business BR-002 (of Table 2) Rule ID Business ComplexityRegion - Complexity BR Category: Rule Name CPL Business Rule Determinewhether excavation notice is within a Complexity Region DescriptionFields Excavation Notice ID, Work Order Number, Task ID, latitudenumber, Required longitude number Rule IF work location is inside agated community Operation THEN Complexity Type = Gated Example Implemen-The complexity regions will be defined by Supervisors using tation theScheduling interface. The complexity region is defined by a complexitytype, high profile reason description (if applicable), and a series oflatitude/longitude coordinates which define a complexity region polygon.

TABLE 5 Third example complexity determination of assessment businessrules 240 Business BR-003 (of Table 2) Rule ID Business Proximity toHistorical High BR Category: Rule Name Profile - High Profile CPLBusiness Rule Use proximity to historical high profile tickets toestimate high Description profile potential Fields Excavation Notice ID,Work Order Number, Task ID, lat number, Required long number, FacilityType Code, Facility Type Description Rule IF work location is within a100 yard radius of a high profile Operation historical location ExampleTHEN Complexity Type = High Profile Potential High Profile PotentialReason = Historical High Profile Reason Implemen- Historical highprofile tickets will be retained with high profile tation reasondescription and latitude/longitude coordinates which define the worklocation.

TABLE 6 Fourth example complexity determination of assessment businessrules 240 Business BR-004 (of Table 2) Rule ID Business Project/HourlyScope - BR Category: Rule Name Complexity CPL Business Rule Determine ifa project/hourly scope applies to the excavation Description noticeFields Excavation Notice ID, Work Order Number, Task ID, Size of LocateRequired Area, Footage, Miles, Bounded By, locate instruction text,comment text, excavation type description Rule IF size of locate area inmiles is greater than 0.5 Operation THEN Hourly Status Indicator = TrueExample Implemen- The decision factors leading to hourly statusdesignation center tation upon the complexity and size of the locatetask, and travel considerations such as whether the worksite is aremote/rural/ desert location. Decisions will be based upon dimensionalfields (Size of Locate Area, Footage, Miles, Bounded By) and keywordfields (locate instruction text, comment text, excavation typedescription). Business rules such as this one, which are derived basedupon billing tables, will need to undergo definition and validationprior to rollout in any given location. This is due to the fact that therules can differ from contract-to-contract, and by area to area within astate.

TABLE 7 Fifth example complexity determination of assessment businessrules 240 Business BR-005 (of Table 2) Rule ID Business Emergency/ShortNotice BR Category: Rule Name Type - Complexity CPL Business RuleDetermine if an emergency/short notice type applies to the Descriptionexcavation notice Fields Excavation Notice ID, Work Order Number, TaskID, Service Type, Required locate instruction text, comment text,excavation type description Rule IF excavation type description containsEmergency Operation THEN service type = Emergency Example Implemen- Fortickets with a routine ticket type, keywords will be searched tation forto determine if a short notice or emergency ticket type should in factbe applied to the excavation notice.

TABLE 8 First example time estimation of assessment business rules 240Business BR-006 (of Table 2) Rule ID Business Locate Count - BRCategory: Rule Name Time TME Business Rule Use number of locates to setan initial estimate of Description ticket duration. Fieldswork_order.work_order_id, Requiredwork_order_locate_task.work_order_locate_task_(—) id Rule IFcount(tasks) > 3 Operation THEN duration = 19 Example Implemen- Thelocate count values and corresponding ticket tation duration values arestored in locate_assess_cond. For example: LOCATE AVG COUNT DURATION 1 72 13 3 19

TABLE 9 Second example time estimation of assessment business rules 240Business BR-007 (of Table 2) Rule ID Business Facility Type - Time BRCategory: Rule Name TME Business Rule Use facility types to be locatedto adjust estimated Description ticket duration Fieldsutil_type_code.displ_type_code, Requiredutil_locate_request.util_type_code,util_locate_request.util_locate_request_id,work_order_locate_task.util_locate_request_id,work_order_locate_task.work_order_id Rule IF Facility Type Codes includeGas Operation THEN duration = duration + 4 Example Implemen- Thefacility type values with associated adjustment values tation are storedin locate_assess_cond. Note that the reason that, for example, the sewernumber might be a negative adjustment, is that statistics might tell usthat 3-locate tickets with sewer are, on average, 3 minutes shorter induration than 3-locate tickets without a sewer locate. For example:FACILITY TYPE DURATION ADJUSTMENT Gas 4 Sewer −3 Water −2

TABLE 10 Third example time estimation of assessment business rules 240Business BR-008 (of Table 2) Rule ID Business High Profile - Time BRCategory: Rule Name TME Business Rule Use high profile certainty toadjust estimated ticket duration Description Fieldshigh_profile_reason_code.displ_reason_code, Requiredutil_locate_high_profile_reason.high_profile_reason_code,util_locate_high_profile_reason.util_locate_request_id,util_locate_request.util_locate_request_id,work_order_locate_task.util_locate_request_id,work_order_locate_task.work_order_id Rule IF High Profile Reason Code =HCPHONE Operation THEN duration = duration * 1.23 Example Implemen- Thehigh profile reason codes will be stored in a decision tation table asan input column, with corresponding multiplier values for ticketduration. For example: HIGH PROFILILE HP REASON DURATION REASON CODEDESCRIPTION MULTIPLIER None no reason 1.15 FiOS Fiber Optic 1.38 HCPHONEHigh Capacity 1.23 Phone Line

TABLE 11 Fourth example time estimation of assessment business rules 240Business BR-009 (of Table 2) Rule ID Business High Profile Potential -Time BR Category: Rule Name TME Business Rule Use proximity tohistorical high profile areas to adjust Description estimated ticketduration Fields work_order.lat_nbr, work_order.long_nbr, Requiredhigh_profile_service_area.high_profile_reason_code,high_profile_reason_code.high_profile_reason_code,util_locate_request.util_locate_request_id,util_locate_high_profile_reason.util_locate_request_id,work_order_locate_task.work_order_id,work_order_locate_task.util_locate_request_id Rule IF High ProfilePotential Reason Code = HCPHONE Operation THEN duration = duration *1.18 Example Implemen- The high profile reason codes will be stored in adecision tation table as an input column, with corresponding multipliervalues for ticket duration. For example: HI PROFILE HP POTENTIALDURATION REASON CODE REASON DESCRIPTION MULTIPLIER None no reason 1.08FiOS Fiber Optic 1.30 HCPHONE High Capacity 1.18 Phone Line

TABLE 12 Fifth example time estimation of assessment business rules 240Business BR-010 (of Table 2) Rule ID Business Complexity BR Category:Rule Name Regions - Time TME Business Rule Use complexity regions toadjust estimated ticket duration. Determine Description if work order isin a complexity region by determining whether the work order location isinside a defined complexity area. Fieldscomplexity_reason_code.displ_reason_code, Requiredcomplexity_service_area.service_area_id, service_area_coordnat.seq_nbr,service_area_coordnat.lat_nbr, service_area_coordnat.long_nbr,service_area_coordnat.spatial_type_code, service_area.service_area_id,work_order.lat_nbr, work_order.long_nbr Rule IF Complexity Region Type =Military Base Operation THEN duration = duration + 35 Example Implemen-The complexity region type codes will be stored in a decision tabletation as an input column, with corresponding multiplier values forticket duration. For example: COMPLEXITY DURATION REGION TYPE ADJUSTMENTGated 15 Military Base 35 Aerial −10

TABLE 13 Sixth example time estimation of assessment business rules 240Business BR-011 (of Table 2) Rule ID Business Service BR Category: RuleName Type - Time TME Business Rule Use the service type (emergency orshort notice) to adjust Description estimated ticket duration Fieldswork_order_locate_task.work_order_id, Requiredexcavatn_notice.ticket_type_code,client_locate_request.excavatn_notice_id,excavatn_notice.excavatn_notice_id,util_locate_request.util_locate_request_id,work_order_locate_task.util_locate_request_id,ticket_type_code.displ_type_code Rule IF Service Type = EmergencyOperation THEN duration = duration * 1.43 Example Implemen- The servicetypes will be stored in a decision table as an input tation column, withcorresponding multiplier values for ticket duration. For example:DURATION SERVICE TYPE MULTIPLIER Emergency 1.23 Short Notice 1.82

TABLE 14 Seventh example time estimation of assessment business rules240 Business BR-012 (of Table 2) Rule ID Business Project/Hourly BRCategory: Rule Name Scope - Time TME Business Rule Adjust duration forproject/hourly scope excavation notice Description Fieldsexcavatn_notice.site_dig_length, Requiredexcavatn_notice.site_dig_width, excavatn_notice.site_dig_depth,excavatn_notice.site_dig_length_uom_code,excavatn_notice.site_dig_width_uom_code,excavatn_notice.site_dig_depth_uom_code,excavatn_notice.excavatn_notice_id,client_locate_request.client_locate_request_id,util_locate_request.client_locate_request_id,work_order_locate_task.util_locate_request_id,work_order_locate_task.work_order_id, Rule IF excavation size greaterthan minimum for project scope status Operation THEN duration =duration * (size of locate area in miles)/0.5 Example Implemen- Theduration adjustment will be proportional to tation the appropriatelocate size field, divided by the baseline appropriate to that field. 1.If the dig dimension fields are not populated, ignore this rule. 2. Ifthe dig dimension fields are populated, and if the dig square footage isover the stored lookup value for square feet (e.g., 10,000), adjust theduration upwards in proportion to the ratio for square footage. 3. Ifthe dig dimension fields are populated, and item 2 does not apply, andif the dig length is above the stored lookup value for length in miles,adjust the duration upwards in proportion to the ratio for linear miles.For example: SCOPE MEASURABLE BASELINE Length of Locate Area 0.5 milesFootage 10000 sq ft

TABLE 15 First example risk estimation of assessment business rules 240Business BR-013 (of Table 2) Rule ID Business Facility BR Category: RuleName Types - Risk RSK Business Rule Use facility types to estimate riskDescription Fields Excavation Notice ID, Work Order Number, Task ID,Facility Type Required Rule IF facility type descriptions contain gasand water Operation THEN Risk = 2.5 + 0.2 = 2.7 Example Implemen- Thefacility types will be stored in a decision table as an input tationcolumn, with corresponding values for additive facility type riskvalues. For example: FACILITY TYPE FACILITY TYPE DESCRIPTION RISK VALUEGas 2.5 Electric 0.7 Water 0.2

TABLE 16 Second example risk estimation of assessment business rules 240Business BR-014 (of Table 2) Rule ID Business Proximity to Historical BRCategory: Rule Name High Profile - Risk RSK Business Rule Use proximityto historical damage reports to adjust estimated risk Description FieldsExcavation Notice ID, Work Order Number, Task ID, lat number, longRequired number, damage latitude, damage longitude, damage amount RuleIF work location is within a 500 yard radius of one or more damageOperation report historical locations totaling $15,000 Example THEN Risk= Risk * 2.0 Implemen- The $15,000 figure cited above is only anexample, the actual tation criteria will be defined by Risk Managementbased upon historical statistics, and will be specific to an individualarea. Historical damage reports will be retained along with excavator,damage cost, facility type, and latitude/longitude coordinates whichdefine the damage location. For example: MIN MAX RISK DAMAGE DAMAGEMULTIPLIER 1 1000 1.1 1000 10000 1.3 10000 100000 2.0 100000 1000000 4.0

TABLE 17 Third example risk estimation of assessment business rules 240Business BR-015 (of Table 2) Rule ID Business Excavator Damage BRCategory: Rule Name History - Risk RSK Business Rule Use excavatordamage history to adjust estimated risk Description Fields ExcavationNotice ID, Work Order Number, Task ID, lat number, long Required number,excavator, excavator damage amount, excavator damage count, excavatorlocate count Rule IF High Profile Potential Reason Code Is Between 100and 300 Operation THEN risk = risk * 2.0 Example Implemen- Historicaldamage reports will be retained along with excavator, damage tationcost, facility type, and latitude/longitude coordinates which define thedamage location. For example: MAXIMUM EXCAVATOR DAMAGE AMOUNT PER LOCATEAS PERCENTAGE OF MEANMAXIMUM EXCAVATOR DAMAGE AMOUNT PER LOCATE ASPERCENTAGE OF RISK MEAN MULTIPLIER 0  50 0.5 50 100 1.0 100 300 2.0 300600 4.0 Additionally, risk multipliers will be applied for excavatordamage count: MAXIMUM EXCAVATOR DAMAGE COUNT PER LOCATE AS PERCENTAGE OFMEANMAXIMUM EXCAVATOR DAMAGE COUNT PER LOCATE AS PERCENTAGE OF RISK MEANMULTIPLIER 0  50 0.5 50 100 1.0 100 300 1.3 300 600 1.8

TABLE 18 Fourth example risk estimation of assessment business rules 240Business BR-016 (of Table 2) Rule ID Business High Profile BR Category:Rule Name Potential - Risk RSK Business Rule Use high profile potentialto adjust estimated risk Description Fields Excavation Notice ID, WorkOrder Number, Task ID, High Profile Required Potential (derived), HighProfile Potential Reason (derived) Rule IF High Profile Potential ReasonDescription = Fiber Optic Operation THEN risk = risk * 4.0 ExampleImplemen- The high profile reason codes will be stored in a decisiontable as an tation input column, with corresponding multiplier valuesfor risk. For example: HP POTENTIAL REASON HP POTENTIAL REASONDESCRIPTION RISK MULTIPLIER 581 no reason 1.8 585 Fiber Optic 4.0 586High Capacity Phone Line 2.5

TABLE 19 Fifth example risk estimation of assessment business rules 240Business BR-017 (of Table 2) Rule ID Business Service Type - Risk BRCategory: Rule Name RSK Business Rule Use the service type (emergency orshort notice) to Description adjust estimated risk Fields ExcavationNotice ID, Work Order Number, Required Task ID, Service Type Rule IFService Type = Emergency Operation THEN risk = risk * 2.85 ExampleImplemen- The service types will be stored in a decision table tation asan input column, with corresponding multiplier values for ticketduration. For example: SERVICE RISK TYPE MULTIPLIER Emergency 2.85 ShortNotice - 2 hours 3.46 Short Notice - 3 hours 3.11

TABLE 20 Sixth example risk estimation of assessment business rules 240Business BR-018 (of Table 2) Rule ID Business Project/Hourly BRCategory: Rule Name Scope - Risk RSK Business Rule Adjust risk forproject/hourly scope excavation Description notice Fields ExcavationNotice ID, Work Order Number, Required Task ID, Hourly Status Indicator,Size of Locate Area, Footage, Miles, Bounded By Rule IF Hourly StatusIndicator = True Operation THEN risk = risk * (size of locate areaExample in miles)/0.5 Implemen- The risk adjustment will be proportionalto the tation appropriate locate size field, divided by the baselineappropriate to that field. For example: SCOPE MEASURABLE BASELINE Sizeof Locate Area 0.5 miles Footage 10000 sq ft

TABLE 21 First example value estimation of assessment business rules 240Business BR-019 (of Table 2) Rule ID Business Billing Rules Per BRCategory: Rule Name Ticket - Value VAL Business Rule Use estimatedlocated value to estimate ticket value Description Fields ExcavationNotice ID, Work Order Number, Task ID, Member Code, Required EstimatedLocated Value (Derived from Billing Rate Tables) Rule IF estimatedlocated value equals $35.50 Operation THEN Value = $35.50 ExampleImplemen- If the billing method associated with the client is “PerTicket” or “Per tation Transmission”, then assume a located, normal,closed ticket. Then lookup the billing rate value associated with themember code associated with the facility locate request and a located,normal, closed ticket.

TABLE 22 Second example value estimation of assessment business rules240 Business BR-020 (of Table 2) Rule ID Business Duplicate Ticket BRCategory: Rule Name Rules - Value VAL Business Rule Apply duplicateticket rules to determine if date worked affects value DescriptionFields Excavation Notice ID, Work Order Number, Task ID, Duplicate RuleRequired Applicability (Derived) Rule IF duplicate rule is trueOperation THEN Value = 0 Example Implemen- A subset of the billingsubsystem business rules deal with the application tation of duplicateticket rules applicable to many service contracts. Many client contractsstipulate that the locating company cannot charge for services performedon a duplicate ticket. These contracts also stipulate what conditionsdefine a duplicate ticket. For example, a contract may define aduplicate ticket as two or more tickets transmitted on the same businessday with identical excavation sites. Business Rule ID: BR-21.0 BusinessRule Name: Duplicate Address on Same Day Business Rule DescriptionCannot bill for subsequent unique Tickets on the same day with the sameaddress Fields Required Ticket#, AddressID, Date Rule Operation Find =[Ticket#, AddressID, Date] If Found > “true” Then No Charge Status onfound record = NC END A variant of this rule involves tickets that mustbe re-worked. For example, the locator may mark facilities on anexcavation site; the excavator subsequently damages or destroys themarkings. In this scenario, the locating company is considered “not atfault” for the re-work, and according to the terms of the contract maycharge the facility for this re-work. Business Rule ID: BR-21.1 BusinessRule Name: Duplicate Ticket, re-work Business Rule Description Cannotbill for duplicate tickets if at fault Fields Required Ticket Number,Ticket Type Rule Operation If Ticket = “Dup” And “At Fault” = True ThenNo Charge Status = NC END Another variant of this rule involves a morestringent definition of what constitutes a duplicate ticket. A contractmay stipulate that the locating company cannot charge the facility fortwo tickets transmitted on the same day within a certain proximity toeach other (although at different addresses). Business Rule ID: BR-21.2Business Rule Name: Duplicate Ticket, Contract-specific attributesBusiness Rule Description Cannot bill for duplicate tickets defined bycontract-specific attributes Fields Required Ticket Number, Ticket Type,Contract-specific attributes Rule Operation If Ticket = “Dup” Then NoCharge Status = NC END

TABLE 23 Business BR-AE-021 Rule ID Business Billing Rates BR Category:Rule Name By Unit- Value VAL Business Rule Apply applicable By Unitbilling business rates and rules Description to determine value FieldsExcavation Notice ID, Work Order Number, Required Task ID, Member Code,Billing Rate Table Criteria and Values Rule IF member code equals 74538and quantity equals 1 Operation THEN Value = 25.75 Example Implemen- Ifthe billing method associated with the client is “By tation Unit”, thenassume a quantity of 1 (this would mean that the lowest lineal feet inthe billing table would be applied). Then lookup the billing rate valueassociated with the member code associated with the utility locaterequest and a quantity of one.

TABLE 24 Business BR-AE-022 Rule ID Business Project/Hourly BR Category:Rule Name Scope - Value VAL Business Rule Adjust value forproject/hourly scope excavation notice Description Fields ExcavationNotice ID, Work Order Number, Task ID, Required Hourly Status Indicator,Size of Locate Area, Footage, Miles, Bounded By Rule IF Hourly StatusIndicator = True Operation THEN value = 4 * (size of locate area inmiles)/0.5 Example Implemen- Value for hourly projects is governed bythe billing tables (per tation contractual terms). Most contracts pay onunit pay rather than hourly. If the contract allows for per hourbilling, then the value adjustment will be proportional to theappropriate locate size field, multiplied by the baseline hours for thatfield, divided by the baseline appropriate to that field. For example:SCOPE BASELINE BASELINE MEASURABLE SIZE HOURS Size of 0.5 miles 4 LocateArea Footage 10000 sq ft 3

TABLE 25 Business BR-AE-022 Rule ID Business Project/Hourly BR Category:Rule Name Scope--Value VAL SCOPE BASELINE BASELINE MEASURABLE SIZE HOURSSize of Locate Area 0.5 miles 4 Footage 10000 sq ft 3

TABLE 26 Business BR-AE-023 Rule ID Business Determine Resource BRCategory: Rule Name Requirements - Skill SKL Business Rule Determineskill requirements for the excavation notice Description FieldsExcavation Notice ID, Work Order Number, Task ID, Required Service Type,Utility Type, locate instruction text, comment text, excavation typedescription Rule IF Utility Type equals Gas AND High Profile Operationequals True Example  THEN Add Resource Requirement for Gas Add ResourceRequirement for Expert Add Resource Requirement for High ProfileImplemen- Examples of skill levels include novice locator, tationexperienced locator, and expert locator. Examples of skill areas includegas qualification, military base eligibility, high profile qualified,and downtown qualified.

While various inventive embodiments have been described and illustratedherein, those of ordinary skill in the art will readily envision avariety of other means and/or structures for performing the functionand/or obtaining the results and/or one or more of the advantagesdescribed herein, and each of such variations and/or modifications isdeemed to be within the scope of the inventive embodiments describedherein. More generally, those skilled in the art will readily appreciatethat all parameters, dimensions, materials, and configurations describedherein are meant to be exemplary and that the actual parameters,dimensions, materials, and/or configurations will depend upon thespecific application or applications for which the inventive teachingsis/are used. Those skilled in the art will recognize, or be able toascertain using no more than routine experimentation, many equivalentsto the specific inventive embodiments described herein. It is,therefore, to be understood that the foregoing embodiments are presentedby way of example only and that, within the scope of the appended claimsand equivalents thereto, inventive embodiments may be practicedotherwise than as specifically described and claimed. Inventiveembodiments of the present disclosure are directed to each individualfeature, system, article, material, kit, and/or method described herein.In addition, any combination of two or more such features, systems,articles, materials, kits, and/or methods, if such features, systems,articles, materials, kits, and/or methods are not mutually inconsistent,is included within the inventive scope of the present disclosure.

The above-described embodiments can be implemented in any of numerousways. For example, the embodiments may be implemented using hardware,software or a combination thereof. When implemented in software, thesoftware code can be executed on any suitable processor or collection ofprocessors, whether provided in a single computer or distributed amongmultiple computers.

FIG. 19 shows an illustrative computer 1900 that may be used forimproving information management, dissemination, and utilization in thelocate industry and other field service industries, in accordance withsome embodiments. For example, the computer 1900 comprises a memory1910, a processing unit 1912 (which may include one or more processors),one or more communication interfaces 1914, one or more display units1916, and one or more user input devices 1918. The memory 1910 maycomprise any tangible computer-readable media, and may store computerinstructions for implementing various components of a ticket managementsystem, such as the ticket parser 210 and the ticket assessment engine230 shown in FIG. 2 and the geographic information system 610 shown inFIG. 6. The processing unit 1912 may be used to execute the instructionsimplementing these software components. The communication interface(s)1914 may be coupled to a wired or wireless network, bus, or othercommunication means and may therefore allow the computer 1900 totransmit communications to and/or receive communications from otherdevices. The display unit(s) 1916 may be provided, for example, to allowa human user to view assessment outcomes produced by the ticketassessment engine 230. The user input device(s) 1918 may be provided,for example, to allow the human user to make any desired manualadjustments to the assessment outcomes.

The various methods or processes outlined herein may be coded assoftware that is executable on one or more processors that employ anyone of a variety of operating systems or platforms. Additionally, suchsoftware may be written using any of a number of suitable programminglanguages and/or programming or scripting tools, and also may becompiled as executable machine language code or intermediate code thatis executed on a framework or virtual machine.

In this respect, various inventive concepts may be embodied as acomputer readable storage medium (or multiple computer readable storagemedia) (e.g., a computer memory, one or more floppy discs, compactdiscs, optical discs, magnetic tapes, flash memories, circuitconfigurations in Field Programmable Gate Arrays or other semiconductordevices, or other non-transitory medium or tangible computer storagemedium) encoded with one or more programs that, when executed on one ormore computers or other processors, perform methods that implement thevarious embodiments of the invention discussed above. The computerreadable medium or media can be transportable, such that the program orprograms stored thereon can be loaded onto one or more differentcomputers or other processors to implement various aspects of thepresent invention as discussed above.

The terms “program” or “software” are used herein in a generic sense torefer to any type of computer code or set of computer-executableinstructions that can be employed to program a computer or otherprocessor to implement various aspects of embodiments as discussedabove. Additionally, it should be appreciated that according to oneaspect, one or more computer programs that when executed perform methodsof the present invention need not reside on a single computer orprocessor, but may be distributed in a modular fashion amongst a numberof different computers or processors to implement various aspects of thepresent invention.

Computer-executable instructions may be in many forms, such as programmodules, executed by one or more computers or other devices. Generally,program modules include routines, programs, objects, components, datastructures, etc. that perform particular tasks or implement particularabstract data types. Typically the functionality of the program modulesmay be combined or distributed as desired in various embodiments.

Also, data structures may be stored in computer-readable media in anysuitable form. For simplicity of illustration, data structures may beshown to have fields that are related through location in the datastructure. Such relationships may likewise be achieved by assigningstorage for the fields with locations in a computer-readable medium thatconveys relationship between the fields. However, any suitable mechanismmay be used to establish a relationship between information in fields ofa data structure, including through the use of pointers, tags or othermechanisms that establish relationship between data elements.

Also, various inventive concepts may be embodied as one or more methods,of which an example has been provided. The acts performed as part of themethod may be ordered in any suitable way. Accordingly, embodiments maybe constructed in which acts are performed in an order different thanillustrated, which may include performing some acts simultaneously, eventhough shown as sequential acts in illustrative embodiments.

All definitions, as defined and used herein, should be understood tocontrol over dictionary definitions, definitions in documentsincorporated by reference, and/or ordinary meanings of the definedterms.

The indefinite articles “a” and “an,” as used herein in thespecification and in the claims, unless clearly indicated to thecontrary, should be understood to mean “at least one.”

The phrase “and/or,” as used herein in the specification and in theclaims, should be understood to mean “either or both” of the elements soconjoined, i.e., elements that are conjunctively present in some casesand disjunctively present in other cases. Multiple elements listed with“and/or” should be construed in the same fashion, i.e., “one or more” ofthe elements so conjoined. Other elements may optionally be presentother than the elements specifically identified by the “and/or” clause,whether related or unrelated to those elements specifically identified.Thus, as a non-limiting example, a reference to “A and/or B”, when usedin conjunction with open-ended language such as “comprising” can refer,in one embodiment, to A only (optionally including elements other thanB); in another embodiment, to B only (optionally including elementsother than A); in yet another embodiment, to both A and B (optionallyincluding other elements); etc.

As used herein in the specification and in the claims, “or” should beunderstood to have the same meaning as “and/or” as defined above. Forexample, when separating items in a list, “or” or “and/or” shall beinterpreted as being inclusive, i.e., the inclusion of at least one, butalso including more than one, of a number or list of elements, and,optionally, additional unlisted items. Only terms clearly indicated tothe contrary, such as “only one of” or “exactly one of,” or, when usedin the claims, “consisting of,” will refer to the inclusion of exactlyone element of a number or list of elements. In general, the term “or”as used herein shall only be interpreted as indicating exclusivealternatives (i.e. “one or the other but not both”) when preceded byterms of exclusivity, such as “either,” “one of,” “only one of,” or“exactly one of.” “Consisting essentially of,” when used in the claims,shall have its ordinary meaning as used in the field of patent law.

As used herein in the specification and in the claims, the phrase “atleast one,” in reference to a list of one or more elements, should beunderstood to mean at least one element selected from any one or more ofthe elements in the list of elements, but not necessarily including atleast one of each and every element specifically listed within the listof elements and not excluding any combinations of elements in the listof elements. This definition also allows that elements may optionally bepresent other than the elements specifically identified within the listof elements to which the phrase “at least one” refers, whether relatedor unrelated to those elements specifically identified. Thus, as anon-limiting example, “at least one of A and B” (or, equivalently, “atleast one of A or B,” or, equivalently “at least one of A and/or B”) canrefer, in one embodiment, to at least one, optionally including morethan one, A, with no B present (and optionally including elements otherthan B); in another embodiment, to at least one, optionally includingmore than one, B, with no A present (and optionally including elementsother than A); in yet another embodiment, to at least one, optionallyincluding more than one, A, and at least one, optionally including morethan one, B (and optionally including other elements); etc.

In the claims, as well as in the specification above, all transitionalphrases such as “comprising,” “including,” “carrying,” “having,”“containing,” “involving,” “holding,” “composed of,” and the like are tobe understood to be open-ended, i.e., to mean including but not limitedto. Only the transitional phrases “consisting of” and “consistingessentially of” shall be closed or semi-closed transitional phrases,respectively, as set forth in the United States Patent Office Manual ofPatent Examining Procedures, Section 2111.03.

1. An apparatus for assessing a locate and/or marking operationrequested in a locate request ticket, the locate and/or markingoperation comprising detecting and/or marking a presence or an absenceof at least one underground facility within a dig area, wherein at leasta portion of the dig area is planned to be excavated or disturbed duringexcavation activities, the apparatus comprising: at least onecommunication interface; at least one memory to storeprocessor-executable instructions; and at least one processorcommunicatively coupled to the at least one memory and the at least onecommunication interface, wherein, upon execution of theprocessor-executable instructions, the at least one processor: A) in afirst stage of assessment, produces a first assessment outcome at leastin part by analyzing at least some ticket information obtained from thelocate request ticket; B) in a second stage of assessment, produces asecond assessment outcome based at least in part on the first assessmentoutcome; and C) controls the at least one communication interface totransmit, and/or controls the at least one memory to store, at least oneof the first assessment outcome and the second assessment outcome so asto facilitate clearing the locate request ticket and/or dispatching atleast one locate technician to perform the locate and/or markingoperation.
 2. The apparatus of claim 1, wherein the at least oneprocessor further: C) receives the ticket information as input; and D)outputs the first and/or second assessment outcomes.
 3. The apparatus ofclaim 1, wherein the at least one processor further accesses auxiliaryinformation from a data storage, and wherein, in A), the firstassessment outcome is produced at least in part by analyzing theauxiliary information.
 4. The apparatus of claim 3, wherein theauxiliary information comprises at least one information type selectedfrom a group consisting of: historical ticket information, facilitiesmaps, digital images, business rules, and excavator history information.5. The apparatus of claim 1, wherein the at least one processor further:E) in a third stage of assessment, produces a third assessment outcomebased at least in part on the first and second assessment outcomes. 6.The apparatus of claim 5, wherein the first assessment outcome comprisesa scope assessment outcome, the second assessment outcome comprises acomplexity assessment outcome, and the third assessment outcomecomprises a risk assessment outcome.
 7. The apparatus of claim 6,wherein, in E), the at least one processor produces the risk assessmentoutcome based at least in part on a number of facilities to be locatedindicated in the scope assessment outcome and a complexity categoryindicated in the complexity assessment outcome.
 8. The apparatus ofclaim 1, wherein the at least some ticket information analyzed in thefirst stage of assessment in A) is a first portion of the ticketinformation, and wherein, in B), in producing the second assessmentoutcome in the second stage of assessment, the at least one processorfurther analyzes at least a second portion of the ticket information. 9.The apparatus of claim 8, wherein the second assessment outcomecomprises a complexity assessment outcome, and wherein, in B), inproducing the complexity assessment outcome, the at least one processoranalyzes at least one type of facilities to be located indicated in thefirst assessment outcome and a service type indicated in the ticketinformation.
 10. The apparatus of claim 8, wherein, in B), in producingthe second assessment outcome in the second stage of assessment, the atleast one processor further: B1) accesses auxiliary information from adata storage; and B2) analyzes the auxiliary information in conjunctionwith the second portion of the ticket information.
 11. The apparatus ofclaim 10, wherein the auxiliary information comprises historicalinformation regarding one or more previously completed locate and/ormarking operations.
 12. In a system comprising at least one processor,at least one communication interface, and at least one memory, a methodfor assessing a locate and/or marking operation requested in a locaterequest ticket, the locate and/or marking operation comprising detectingand/or marking a presence or an absence of at least one undergroundfacility within a dig area, wherein at least a portion of the dig areais planned to be excavated or disturbed during excavation activities,the method comprising: A) in a first stage of assessment performed bythe at least one processor, producing a first assessment outcome atleast in part by analyzing at least some ticket information obtainedfrom the locate request ticket; B) in a second stage of assessmentperformed by the at least one processor, producing a second assessmentoutcome based at least in part on the first assessment outcome; and C)transmitting via the at least one communication interface, and/orstoring in the at least one memory, at least one of the first assessmentoutcome and the second assessment outcome so as to facilitate clearingthe locate request ticket and/or dispatching at least one locatetechnician to perform the locate and/or marking operation.
 13. Themethod of claim 12, further comprising: C) receiving the ticketinformation as input; and D) outputting the first and/or secondassessment outcomes.
 14. The method of claim 12, further comprisingaccessing auxiliary information from a data storage, wherein the firstassessment outcome is produced at least in part by analyzing theauxiliary information.
 15. The method of claim 14, wherein the auxiliaryinformation comprises at least one information type selected from agroup consisting of: historical ticket information, facilities maps,digital images, business rules, and excavator history information. 16.The method of claim 12, further comprising: E) in a third stage ofassessment, producing a third assessment outcome based at least in parton the first and second assessment outcomes.
 17. The method of claim 16,wherein the first assessment outcome comprises a scope assessmentoutcome, the second assessment outcome comprises a complexity assessmentoutcome, and the third assessment outcome comprises a risk assessmentoutcome.
 18. The method of claim 17, wherein E) comprises producing therisk assessment outcome based at least in part on a number of facilitiesto be located indicated in the scope assessment outcome and a complexitycategory indicated in the complexity assessment outcome.
 19. The methodof claim 12, wherein the at least some ticket information analyzed inthe first stage of assessment in A) is a first portion of the ticketinformation, and wherein, in B), producing the second assessment outcomein the second stage of assessment comprises analyzing at least a secondportion of the ticket information.
 20. The method of claim 19, whereinthe second assessment outcome comprises a complexity assessment outcome,and wherein, in B), producing the complexity assessment outcomecomprises analyzing at least one type of facilities to be locatedindicated in the first assessment outcome and a service type indicatedin the ticket information.
 21. The method of claim 19, wherein, in B),producing the second assessment outcome in the second stage ofassessment comprises: B1) accessing auxiliary information from a datastorage; and B2) analyzing the auxiliary information in conjunction withthe second portion of the ticket information.
 22. The method of claim21, wherein the auxiliary information comprises historical informationregarding one or more previously completed locate and/or markingoperations.
 23. At least one non-transitory computer-readable storagemedium encoded with at least one program including processor-executableinstructions that, when executed by a processor, perform a method forassessing a locate and/or marking operation requested in a locaterequest ticket, the locate and/or marking operation comprising detectingand/or marking a presence or an absence of at least one undergroundfacility within a dig area, wherein at least a portion of the dig areais planned to be excavated or disturbed during excavation activities,the method comprising: A) in a first stage of assessment, producing afirst assessment outcome at least in part by analyzing at least someticket information obtained from the locate request ticket; and B) in asecond stage of assessment, producing a second assessment outcome basedat least in part on the first assessment outcome.